Where are the Core Contributors?

A presentation by @felixarntz

Benefits of contributing to Core

• work on a software that powers more than a quarter of the web
• get to know WordPress Core from the inside out
• develop clean with a focus on documentation and unit tests
• write code with accessibility in mind
• put emphasis on areas that you would like to see improved

Research Methods

• Twitter Survey
• Detailed Survey for Core Developers
• several blog posts

Why I was frustrated

I was rushing it too much and had not read the handbook enough.

I had no clear goal in mind.

"Start with something small to get to know the code and the community. Learn the WordPress philosophies."

- Pascal Birchler, Guest Committer

"Find something you care about or that motivates you - contributing for the sake of contributing does not work for anybody as a long-term plan. This might be a component, or project, or triage, or testing, or whatever."

- Helen Hou-Sandi, Lead Developer

Why do people not contribute to Core?

I really don't have enough time!

"I think a good rule of thumb that will scale with the community as it continues to grow is that organizations that want to grow the WordPress pie (and not just their piece of it) should dedicate 5% of their people to working on something to do with core — be it development, documentation, security, support forums, theme reviews, training, testing, translation or whatever it might be that helps move WordPress mission forward."

- Matt Mullenweg, Co-Founder in Five for the Future

WordPress Core philosophies

• only features for the majority are built-in
• "Decisions not Options"
• no squeezing-in of possibly unfinished features or enhancements
• no refactoring for refactoring's sake
• developer-focussed enhancements must lay a foundation for user-focussed enhancements

But the code quality is terrible!

"The code you wrote yesterday is almost always worse than the code you wrote today. WordPress has been writing code for 13 years—that's a lot of code written in yesterdays."

- Jeremy Felt, Core Developer

"If you want to judge a piece of software by the "newness" of it's codebase, then WordPress isn't going to win any awards. [...] However, if you want to judge software by its commitment to maintaining backwards compatibility, WordPress is a model example. There are tradeoffs, to be sure, but figuring out how to keep improving the software without breaking things for existing users is part of the engineering challenge that makes developing for WordPress fun, in my opinion."

- Joe McGill, Contributing Developer

But when will PHP 5.2 be dropped?

"WordPress is not prohibiting any hosting services from upgrading to more modern, secure versions of PHP. However, WordPress has decided there is much more to be lost (in user trust, etc.) by artificially breaking sites that are running on older versions of PHP (which most users know nothing about) rather than trying to be a model of modern code."

- Joe McGill, Contributing Developer

"Pitting the minimum PHP compatibility of WordPress against other software packages in the PHP space is a bit of a straw man exercise. WordPress powers 26 percent of the web *because* it puts users first – a particular philosophy and feat no other package in the space can claim."

- Drew Jaynes, Core Developer

But I think this is all the wrong approach!

"I think it's important to contribute to projects that align with your philosophies. If philosophically you are opposed to the reasons why WordPress does or has done these things, then it is probably not a good fit. There is a much bigger ecosystem of open source software that is also critical to the web - I think encouraging open source stewardship in general is a better approach than perpetuating a WordPress-centric bubble."

- Helen Hou-Sandi, Lead Developer

Getting Started with Contributing

• recommended way is VVV; looks complicated at first if you haven't used Vagrant before, but it sets up the entire development suite required to develop for Core
• tickets are filed on Trac
• patching happens via SVN (recommended) or Git

But SVN sucks!

Even if you prefer to use Git, using SVN for Core development shouldn't be too hard.

svn update
grunt patch:12345
grunt upload_patch:12345
svn revert -R *

Plus you don't even need to set it up on your local machine if you use VVV.

But I really hate SVN and wanna use Git!

For some reason it's not commonly known, but you can use Git for contributing.

"If developers wanted to contribute through git, there are a myriad of tools enabling them to do so. We already get many patches from a git checkout of WordPress. The amount of existing SVN infrastructure around WordPress makes moving to Git a very hard sell, the work needed to port everything over still outweighs the benefit of using Git over SVN."

- Konstantin Obenland, Guest Committer

But Trac sucks!

Let's step back a little and compare Trac with GitHub. While GitHub looks nicer and you're probably used to it, it has several problems for a large project like WordPress.

"If development happened mainly through GitHub, there would be so many open issues that new contributors would feel even more lost than they might be already. Pull Requests becoming outdated and, having to fork contributor's forks of WP to continue working on their PR—there are quite a few things that git advocates have not thought through when it comes to workflow. Things that are necessary to have a plan for with a project of the size of WordPress."

- Konstantin Obenland, Guest Committer

Dealing with Frustration

You open an enhancement ticket. It's closed as wontfix.

You work on a patch for hours. It gets rejected.

You're happy to have reported a bug, but it's a duplicate.

Your ticket remains without any interaction for weeks.

That person closed my ticket although I know others who want it too!

"Lack of traction is bad for WordPress and all the involved contributors on a ticket. It usually isn't because of 1 specific developer, and if it is, it's a lead developer who knows what they are talking about. But valid points have always helped changing people's opinions."

- Pascal Birchler, Guest Committer

On Slack everyone's so nice, but Trac feels rude.

"I do think the tone on tickets can be a bit more "official" than the Slack channel. My own personal anecdote would be that Trac feels like a more "historic" document, which makes me want to be more precise in my feedback/contributions, rather than adding conversational comments like I would during a Slack conversation."

- Joe McGill, Contributing Developer

That person rejected my proposal, and didn't even thank me for my initiative!

"We do have notifications now that show when a ticket is a contributor's first, second, third, or fourth. That helps guide others to be more welcoming while responding. The strictness can come from the conversations needing to be technical and clear so that the right message is being conveyed."

- Jeremy Felt, Core Developer

"We're often used to give short answers, missing little stuff like "thank you", "a quick note", "not a big deal", "please" etc. Even if you do add that, with text-only communication there will be misunderstandings."

- Pascal Birchler, Guest Committer

Wontfix.

"The issue isn't the idea that the patch or ticket was rejected. That is a normal part of software. It’s the verbiage. The label should be called, and I’m joking here, 'OMG thank you soooo much for this awesome work you’ve done but at this point, for one of a variety of reasons, we can’t roll this in and I hope to get you more info on it but right now I’m doing tons of additional work, sometimes for free.'"

- Chris Lema, WordPress Evangelist in There is always an us but not always a them

My ticket hasn't received any attention in weeks!

"A new idea with or without a patch and no followup is in all likelihood going to be missed. Creating a ticket and walking away is a recipe for inactivity. New contributors need to be actively advocating for their ideas, participating in the weekly dev chats, and generally be open to feedback of all types."

- Drew Jaynes, Core Developer

"Patch/ticket review has gotten better but can still be a bottleneck, and this often comes down to a lack of active component maintainers and the perception that only committers can review patches. Anybody can review a patch, which includes testing it."

- Helen Hou-Sandi, Lead Developer

Becoming a persistant contributor

There is some kind of trust level around - as in every community.

• Consider becoming a component maintainer.
• When you become more known among contributors and have proven that your ideas, mindset and code comply with the project’s goals, it will be easier to push bigger initiatives.
• If you face frustration along the way but still think the project is a fit for you, shake it off and continue – you will get there.

Final Advices

"After you've worked on a few individual tickets and have a sense of the workflow, I would highly recommend finding a component or feature project that you're interested in and join the effort to build or maintain that component."

- Joe McGill, Contributing Developer

"Keep at it, trust the more seasoned contributors, ask them questions, don't take it personal when a proposal or a patch doesn't get accepted."

- Konstantin Obenland, Guest Committer

Thank you!

Felix Arntz

Plugin Developer / Core Contributor / Freelancer

• felix-arntz.me
• profiles.wordpress.org/flixos90
• github.com/felixarntz
• twitter.com/felixarntz