The qualities of a great WordPress contributor

“A few years ago, there were only a handful of people with commit access. Now there are 15 or so with permanent commit. How has this benefited the development of WordPress? In your opinion, is it possible to have too many people with core commit access? What advice can you give for those looking to either gain temporary or permanent access?”

Jeff at WP Tavern asked me these questions about a month ago, and while writing a reply, I realized it’d make a great blog post. I’m going to answer these questions, but I also strongly believe you don’t need commit access (or even desire it) to be a great contributor who commands respect and influences the project. So perhaps the most important question I hope to answer here is this: What are qualities of a great open source contributor?

A committer is a contributor with the ability to modify the main WordPress repository. If you’re used to a decentralized model, this would be those with push/write access. There have been around three dozen committers to WordPress over the last decade; almost twenty currently have access. But in 2009, there were just five.

The lead developers all got together for the first time at WordCamp Orlando in December 2009, right around the time I started contributing. (So no, I was not there.) At the time, there weren’t any committers who weren’t lead developers. They set a goal to expand the number of people. When they added Dion Hulse that January, Matt wrote:

One of the goals for the team in 2010 is to greatly expand the number of people with direct commit access, so the emphasis is more on review and collaboration. Right now commit access is tied up with being a “lead developer,” of which we’ve always found a small group of 3-5 works best, but now we want commit to be more a recognition of trust, quality, and most importantly activity, and something that can dynamically flow in and out as their level of commitment (har har) changes and decoupled from the “lead dev” role.

I think it’s great to empower and reward contributors with commit access. When Matt and I are together, he likes to challenge me with one particular thought experiment — he’ll ask what would happen if we just gave everyone the ability to push a change to WordPress. Obviously, that wouldn’t work. But at what point does it not work? 10? 50? 100? 1000? I don’t think it’s a raw minimum or maximum number. I think it has a lot to do with our philosophies and how we organize ourselves, for example.

How to be a great contributor

I’ve been involved in identifying and mentoring new committers for a few years now. Certainly, quality of contributions is important, but it’s only one small piece of the puzzle. Especially as contributors start to start review contributions by others, you start to see a number of other qualities. For example, what’s their judgment and temperament like? Also, you can have the most amazing judgment out there, but without strong communication skills, we’ll never know.

Attention to detail is extremely important. As a committer taking on the shared responsibility of maintaining a large, sprawling codebase, you need to always be thinking about edge cases, big ramifications of seemingly small changes, backwards compatibility, etc. We’re building something pretty amazing, but at a fifth of the internet, it’s also being run at such an incredible scale that all changes are risky. We’re very cognizant of this: once we hit a release candidate, every commit needs to first be reviewed by two lead developers, even if it’s a lead developer who authored it. It helps to be honest when, for example, you know you are not confident. It’s important to be humble, which includes knowing when to ask for help, when you’re wrong, and when to change your mind. Along these lines, I like citing software developer Havoc Pennington:

In the presence of good rationale, maintainers should be willing to change their mind often.

It’s not about making mistakes, because we all make them. Being thorough and acutely perceptive just goes an incredibly long way to writing and reviewing code. (Word of the day: perspicacious.)

We also take a lot of pride in building user-centric software. You don’t need to have amazing UX skills, but strongly believing in our core philosophies goes a long way. These philosophies have roots in another of Pennington’s essays on creating good user interfaces.

There is a lot of history embedded in the code, and we don’t make changes without a deep understanding of the code around it. So it’s important to want to learn it. You need to be curious and love to learn. At the same time, the more you work with a codebase, the more frustrated you’re bound to get with it, so you need to have a lot of patience. For years I’ve not only been building a mental map of WordPress in my head, but I’ve been overlaying it with a potential roadmap.

Patience when communicating with others can reveal a lot about temperament. Thousands of people represent the WordPress project in some way, so it’s important for contributors to lead by example. If a person feels he was treated poorly when he reported a bug, he’s not likely to contribute again. Karl Fogel covers an aspect of this in Producing Open Source Software:

Sometimes someone shows technical skill and an ability to work within the project’s formal guidelines, yet is also consistently belligerent or uncooperative in public forums. That’s a serious concern; if the person doesn’t seem to shape up over time, even in response to hints, then we won’t add him as a committer no matter how skilled he is. In a volunteer group, social skills, or the ability to “play well in the sandbox”, are as important as raw technical ability.

Committers are essentially ambassadors of the WordPress project, so it’s important that they lead by example. It doesn’t serve the project to give a leadership role to someone who is often rude, cantankerous, or overly critical. Along the same lines, knowing how to actually handle a “poisonous person” is helpful. It’s good to reach out to contributors to talk about this kind of behavior.

How project priorities affect contributions

So what advice can I give to those looking to become a committer? It probably isn’t something I’d make a goal. I’d just work hard to make WordPress better. Regardless of your “access” you are sure to make an impact and receive respect from others.

I got my start doing a lot of thankless tasks during the 2.9 and 3.0 cycles. I tested the heck out of some of the newer features like trash, and weighed in and patched bugs. When multisite started to be merged in 3.0, I would sit there for hours dissecting it and seeing what I could do to understand it (and clean it up). I volunteered for tasks no one else wanted to work on because I knew it was important to the project. I’d look out to see which tickets were being flagged for the current release, then tackle them, one by one. It was definitely noticed that the committers could reliably turn to me during crunch times to get things done. Being responsive to the needs of the project is key.

I’m not suggesting you need to work on things you don’t enjoy. You can totally make the project better while sticking to an area of interest. You could even spend time in an area that overlaps significantly with what you’re employed to do, if contributing isn’t just a hobby for you. For example, Scott Taylor initially invested a lot of his time on making audio and video support better while he was at emusic (though music is certainly also passion of his). A lot of contributors have stepped up to improve an API after digging deep into it for a project.

Worth mentioning: Discussing with your employer about contributing is not an easy conversation. While hiring based solely on open source contributions can be fraught, companies that encourage their employees to contribute are helping themselves, too. Contributing not only gives back or helps to establish a voice in the community, but it’s also an enriched learning environment. I learned more in my first three months contributing than I did in three previous years of web development. It never hurts to have a subject matter expert on staff. And if you’re a consultant, you’ll be worth more to your clients.

Many committers are “generalists” with a wide knowledge of WordPress, who have contributed extensively to all sorts of areas. Some are “specialists,” who work hard on a particular feature (perhaps a feature plugin), component (like multisite), or have a particular focus (like JavaScript). Becoming an expert in an area is hugely beneficial to the project. Some of our more recent process changes mean we are trying to empower more people to help “maintain” these different areas. This is great because it means more contributors will be able to make bigger differences, whether it’s triaging new or old tickets, providing feedback, helping to build out a roadmap for a particular component, or mentoring newer contributors. Not everything is exciting (like digging through old tickets on Trac, as if looking for diamonds in the rough) but your contributions will definitely be noticed.

You may not see it right away when you start out as a contributor, but it’s important to place the project’s goals ahead of your own. You might have reported a dozen tickets and it’s possible you disagree with how ten of them were handled. You can and should work to fix tickets you reported, but at some point, you’ll hopefully run out of those and need to look elsewhere to get your fix. Many contributors — including every committer — have “wish lists” or “pet projects” or “pet bugs” that they still haven’t gotten to, because they realize the project isn’t ready for them, or because their solution isn’t ready for the project, or because it simply isn’t a priority.

Some have said contributing to WordPress is more politics than code. I don’t think that’s true, but it can be easy to think that when you wonder why some things are moving faster than some individual ticket (of thousands). Scott Taylor recently wrote:

For a lot of people, I know the wait can be frustrating, but I would try viewing it in a larger context: we all have things we would love to go in immediately, but as responsible committers, we have to weigh the pros and cons of tossing code onto 20% of internet. I have tickets that have been open for 7 releases, but for each I either:

  1. don’t think the idea is fully-baked
  2. don’t have absolute confidence that the feature/code is necessary
  3. haven’t made a good enough case for it
  4. haven’t provided bulletproof evidence that it’s going to make WP better

More from Havoc Pennington:

Please don’t assume that the key issue for accepting a feature is whether there’s a patch. It isn’t. It’s easy to write a patch. It’s hard to maintain a software project over the long term. Maintainers absolutely have to understand the rationale for each feature, not just rubber stamp the patches. If they don’t understand a feature they can’t maintain it over time. There will be future decisions about how the feature works, or how related features work, and the maintainer will have to make those decisions.

This is probably the least understood reason why certain tickets move slower than others: maintaining things is hard. When something is committed, that committer is taking on a lot of extra responsibility. That bug or feature isn’t necessarily the problem — it’s also the bugs, features, and even security issues that follow it. Our firm commitment to backwards compatibility also means it will be harder to take a wrong turn now and correct it later. Very simply, there are a lot of things to work out.

What does describe WordPress well is that it’s more communication than code. I think this is also incredibly healthy. Communication and collaboration are the lifeblood for an open source project.

As Matt cited in 2010, activity for committers is important, as you need to be following development discussions and an often fast-moving codebase. A lot of contributors don’t venture beyond the bug tracker; you’ll want to pay close attention to the development blog and be active in IRC. Some of our committers have gotten less active over time, and that’s also okay, because we know we can trust their judgment. When they wish to commit something, they’ll know they’re behind and will first need to get caught up.

So ask yourself how you want to contribute, and what kind of impact you want to have. Some of our best contributors don’t have commit access, including a few who are significantly smarter than me. They either don’t want the responsibility of making decisions as a maintainer, or don’t have the time for it — and that’s totally okay!

How the WordPress lead developers choose committers

In the interest of transparency and avoiding mystery, let me explain the specifics of the decision-making process. For a few years now, we’ve been granting commit access for individual release cycles at first, on a temporary or “guest” basis. It’s often because they’re working on a particular feature, though it of course can double as a trial period. Sometimes a contributor is given commit access to a particular area or focus. (We use a relaxed approach for partial or “component” commit.)

The lead developers keep pretty close tabs on what’s going on, and we always have people in mind for commit access. Typically, someone catches our eye and we’ll privately mention it to each other. This can happen very early on — sometimes, someone’s first bug report or patch just knocks your socks off. If you do good work, you will get noticed. A potential committer will often end up working on projects one-on-one with an existing committer. These projects end up being great opportunities to mentor that contributor, see what they’re interested in, get a feel for how they think, and so on. We make it a point to request feedback from other core developers and guest committers, what they think of so-and-so.

The lead developers discuss commit access over email before each release cycle. We’ll review current guest committers and proposed new committers. We mention contributors we’re keeping an eye on. Nothing is rigid about this process. There’s no formal “voting” procedures; there’s never been anything short of a consensus. A proposal can come at any time, not just at the start of a cycle (that’s just when we check in on guest committers). A few times we’ve essentially agreed ahead of time to grant commit access once conditions are met. Some examples: they’ll be ready in another month or two; we want a documentation committer, so let’s see who steps up after we start this initiative; or let’s try to get the main developer of this feature plugin commit access if the merge goes well. (Building features as plugins first has perhaps lessened the need for granting someone commit access for a cycle, but I think it’s too early to tell.)

Once a committer accepts, I usually go over a few guidelines. They go something like this:

  • For your first half-dozen commits or so, run them by me or another lead (either in IRC or privately) just while you get the hang of things.
  • The first sentence of your commit message gets used as the subject for the wp-svn mailing list. Add more details after that and don’t forget props or tickets.
  • Try to be on IRC when you’re committing; for the occasional instant feedback.
  • Aim to wait for some kind of consensus on the big or controversial stuff. Even Ryan and I, for example, rarely move on anything hefty without the other glancing at it. On the other hand, don’t let us slow you down — we are known bottlenecks.
  • Ryan and I miss things weekly and we have 12,000 commits between us. Code can always be reverted. Peter will revert you at least once; wear it as a badge of honor.

Often, the final trigger for commit access is I’m getting tired of committing all of your patches, because I never need to do anything to them. That’s what Ryan Boren told me on February 8, 2010, when he asked if I wanted commit, four years ago tomorrow. I’ve been really lucky to have had the pleasure of passing that sentiment on.

Joomla World Conference

I’m attending Joomla World Conference in Boston this weekend. Wait, what?

WordPress founder Matt Mullenweg is giving a keynote address on Sunday. I’m really glad we’re here, as engagement across communities is vital. Too many web communities are isolated, and I suspect there is a lot the WordPress and Joomla communities can learn from one another.

The two projects have a lot of similarities: we love open source and the GPL, love-hate PHP, and have sprawling communities and ecosystems. We’re also both forks of other software (b2 and Mambo), and we are both trying to advance and evolve quickly, as well as better define what exactly we are (blog/CMS/platform/framework). Of course, there are many differences. I especially want to talk about and compare development philosophies. I quote from and reference our philosophies document often, and we practice them as much as we preach them. Among them: making decisions instead of adding UI options, designing for the majority of users, stressing the importance of deadlines, and building something that is lean, fast, and works out of the box.

We receive a lot of praise for our user interface, and we strongly believe that the user experience comes first. But for us, that includes making sure we’re always backwards compatible, even across major versions. While we shoulder more technical debt this way, we’ve found it is better than passing that pain off onto our users and the other developers in our ecosystem. The UI is awesome, but our commitment to BC may be the most understated reason why WordPress has grown to power 20 percent of the web.

One section on that philosophies page actually needs to be updated: in “Striving for Simplicity,” we talk about how we worked to ensure WordPress can be updated in a single click. But in WordPress 3.7, released last month, maintenance and security releases now occur automatically. Zero clicks given! A self-updating web application? Without breaking anything? Yes and yes. The technical challenge was immense, but so was communicating it to our users and developers. If anything ever fails on them, they won’t be inclined to trust us again — whether that’s an update or the simple act of trying to save a post. (That’s also why we focused on stronger autosaves the previous release, WordPress 3.6, which was released only two months prior.)

I’ve gotten a warm welcome so far. Want to talk about development philosophies? How releases are run? How our projects are organized? How decisions and features are made? How to evolve our complicated platforms? Want to chat about lowest common denominators, old versions of PHP, crappy servers, and the crazy things we all see in the wild? Why do we do X? Why on earth don’t we do X? Great. Come find me. I’ll be walking around wearing a WordPress shirt, or you can hail me on Twitter (@nacin).

I have some stickers as well, if you want one.

Firefox makes a decision, removes an option

Back in 2011, I wrote about how we need to make decisions in open source. This is not a new idea — it is rooted in the guiding philosophies for WordPress to make decisions, not options.

Perhaps unsurprisingly, Hacker News is now up in arms about Firefox 23 removing the “Disable Javascript” option. I’m really glad to see ex-Mozilla guy Gregory Koberger with the top comment there, linking to a fantastic piece called Checkboxes that kill your product. “A little historical baggage can be a dangerous thing when multiplied by a few hundred million individuals,” wrote Alex Limi, who does product design strategy at Mozilla. (I had a chance to meet Gregory at a conference in 2011 and he’s a great web dev follow on Twitter.)

In WordPress 3.5, I spearheaded a quiet but major purge of UI options. We removed ten of them. And we moved another off its own page, which let us drop down to six settings pages, down from eight in 2010. My napkin math shows we removed 15 percent of all settings. That’s a huge improvement. Some of these were break-your-site options. Others might cause confusion. And we have ongoing efforts to simplify or improve a few other settings as well.

When talking about decisions versus options, I often tell the story of Firefox 4’s change to tabs on top. I even watched a seven-minute YouTube video explaining exactly why this was a better user experience. (And I couldn’t agree more.) But then, at the end of the video, after all of the convincing arguments, they mention there is an option to put it back. My heart sank. It was a compelling video, but the community forced them to compromise by keeping in core a completely separate workflow, despite making a strong statement that it was clearly inferior. Firefox is highly extensible. An extension could have changed it back. By keeping it in Firefox core, you now have double the user flows to test, your QA testing suffers, users suffer, everything suffers.

Firefox may be the people’s browser, it may be the one true open browser project, but that doesn’t mean it is a kitchen sink. I didn’t actually realize that Firefox still had the Disable JavaScript option. I have been using an extension to toggle JavaScript in Firefox, as sometimes I have to test no-JS situations. The fact that I didn’t know the option existed, though, is only one indication that this is a problem. This single option enables a user to do so much damage to their web browsing experience that it is absurd for it to exist. This is Limi’s point.

I can’t quote from the writings of GNOME contributor Havoc Pennington enough. His posts did a lot to inform early development of WordPress, and continue to make an impact today. Here’s what I shared in 2011:

It turns out that preferences have a cost. Of course, some preferences also have important benefits – and can be crucial interface features. But each one has a price, and you have to carefully consider its value. Many users and developers don’t understand this, and end up with a lot of cost and little value for their preferences dollar.

  • Too many preferences means you can’t find any of them.
  • Preferences really substantively damage QA and testing.
  • Preferences make integration and good UI difficult.
  • The point of a good program is to do something specific and do it well.
  • Preferences keep people from fixing real bugs.
  • Preferences can confuse many users.

I find that if you’re hard-core disciplined about having good defaults that Just Work instead of lazily adding preferences, that naturally leads the overall UI in the right direction. Issues come up via bugzilla or mailing lists or user testing, and you fix them in some way other than adding a preference, and this means you have to think about the right UI and the right way to fix problems. Basically, using preferences as a band-aid is the root of much UI evil.

For more written by Pennington, see these essays from 2002 and 2004.

Perhaps tellingly, I also wrote then “WordPress is known for its simplicity and usability, but I can still think of a half-dozen options I wouldn’t hesitate to remove under the right circumstances.” In WordPress 3.5, the circumstances were right. Promise kept!

Addendum: In that long Hacker News thread (300 comments and climbing) Gregory also commented:

Try an extension? Power users aren’t the target market for this decision, and that’s why add-ons exist.

This is also a great time to review the sections Designing for the Majority and The Vocal Minority on the WordPress philosophy page.

In Open Source, Learn to Decide

Dave Winer tweeted a photo of a weird, verbose, and confusing Android options screen. I love Android, but like most open source projects, it falls victim to the proliferation of options, rather than making decisions for its users.

When explaining this to developers at conferences, I generally mention the preference panels in Adium, a Mac OS X chat client. It practically has an Advanced tab for the Advanced tab. Stuff everywhere. Problem is, when there are too many options, your users can’t find any of them.

Open source doesn’t need to be this bad. One of the tenets of the WordPress philosophy is Decisions, Not Options:

When making decisions these are the users we consider first. A great example of this consideration is software options. Every time you give a user an option, you are asking them to make a decision. When a user doesn’t care or understand the option this ultimately leads to frustration. As developers we sometimes feel that providing options for everything is a good thing, you can never have too many choices, right? Ultimately these choices end up being technical ones, choices that the average end user has no interest in. It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users.

Buried in the annals of WordPress, a release philosophy document was heavily inspired by the writings of GNOME contributor Havoc Pennington. On preferences, he wrote (nearly 10 years ago) —

It turns out that preferences have a cost. Of course, some preferences also have important benefits – and can be crucial interface features. But each one has a price, and you have to carefully consider its value. Many users and developers don’t understand this, and end up with a lot of cost and little value for their preferences dollar.

  • Too many preferences means you can’t find any of them.
  • Preferences really substantively damage QA and testing.
  • Preferences make integration and good UI difficult.
  • The point of a good program is to do something specific and do it well.
  • Preferences keep people from fixing real bugs.
  • Preferences can confuse many users.

I find that if you’re hard-core disciplined about having good defaults that Just Work instead of lazily adding preferences, that naturally leads the overall UI in the right direction. Issues come up via bugzilla or mailing lists or user testing, and you fix them in some way other than adding a preference, and this means you have to think about the right UI and the right way to fix problems. Basically, using preferences as a band-aid is the root of much UI evil.

WordPress is known for its simplicity and usability, but I can still think of a half-dozen options I wouldn’t hesitate to remove under the right circumstances. Many WordPress plugins subject their users to too many options. Don’t add settings screens simply because you know how.

Challenge yourself. Learn to decide.