Thoughts on Contributing to WordPress Core

I was an early user of WordPress in the grand timeline of events.

Officially, my first long term installation was WordPress 1.5 in 2005. That site was a chronicle of my dad’s bicycle ride across the country and has been running continuously for about 9 years. It was even “0wn3d” at some point by hackers when I didn’t upgrade and I had some cleaning up to do.

The other day I upgraded this same installation from 3.4.1 to 3.8 and had no troubles at all. That made me happy.

I don’t remember giving much of a thought to contributing for many years. I created many various blogs using WordPress and hunted the Internet for things I could add.

I used Matt’s blog to figure out asides. I created themes with the fancy CSS. I thought BackPress was the future!

It took me until 2009 to register for my first plugin while I joined the excitement around rssCloud. Joseph Scott beat me to it and I never actually populated the repo. 🙂

I like to think of this as the “They” period.

They released an update. They should include this feature. They make it easy to have a blog.

In 2011 I quit my 12 year career, we traveled around Europe a bit, and then landed in Portland. Without a job—and without knowing the first thing about freelancing—I decided that I should attend that year’s WordCamp.

Mostly because it was only $20 and lunch was included.

The addiction hit pretty hard once I got a sense of the community. For all the grief that unconference sessions can sometimes get, they were amazing for me.

We stood around in a group with Joey and discussed developer challenges and solutions. I started talking about deployment with Zack, a concept we’re still trying to solve today. I watched a fascinating Nacin explain WP Query to a room full of developers. I got lunch!

Hooked.

I quickly started in on my plugins. All about data portability, I made one for YouTube and for Instapaper. A fantastic automatic featured image post creator that the blackhat community LOVES. A way to set the posts per page value for any type of page view. I started following more of the WordPress community, absorbing all the information I could get.

You could call this the “Outsider” period.

I wasn’t necessarily referring to the WordPress project as “They” any longer, but I wasn’t entirely familiar with the goings on. While the community was absolutely approachable at WordCamp, things suddenly seem so different without faces in an online place where everybody else knows what they’re doing.

Hint… that last sentence couldn’t be less true. 😉

In December of 2011, Zack did some great convincing on two sides. I gave in to being bad at freelancing, applied for a full time job with 10up, and Jake saw enough to take me on.

Things changed quick as I was thrust into the world of WordPress full time.

My immediate charge was to build the new UniversalSports site from scratch over the next few months to be hosted on WordPress.com VIP. I learned so much during this period through building and failing and code reviewing and everything.

And the “We” period began.

“They” switched to “We” inside my head and I became a community member. I paid attention to dev chats for the most part. I read code. I planned out what WordCamps I wanted to attend and started thinking of topics to speak on.

While helping Helen troubleshoot an issue with one of her client sites, we stumbled on a mistyped character in some oEmbed code. I frantically created a ticket and a patch with her guidance, worried the entire time that all of the people who already know all the answers were going to come in and fix it before I had the chance.

But that doesn’t happen. There’s always a place to contribute. Nobody comes out to bite when you create a ticket, nobody slaps your code down. In fact, the community loves when a new face appears on Trac with any type of activity.

The patch was eventually committed and I felt amazing. On the contributors list for 3.4!

Freaking stellar.

This is where the train starts moving. Once I was past that hurdle, a whole new world opened up. I wanted to contribute!

But finding a place still seemed so hard!

Becoming a Contributor.

I’m going to shift gears a bit, because this story is so long and there’s so much more to tell. The rest is a natural continuation summed up into what I think you should take away from this.

Types of patches in Jeremy’s perceived order of difficulty:

1. In the process of developing X, I found this quick Y. This is what my first patch came from. While not working directly on WordPress core, something came up. When investigated, it turned out to be a bug. Once character patch, good to go. The best thing that can be done to create patches for WordPress core is to spend time in WordPress core.
2. I want to fix a bug. There are many, many things in WordPress waiting to be fixed that only need attention. This involves finding a place you’re interested in and testing. If you can reproduce a reported issue, you’re more than half way to a solution.
3. I want to introduce this enhancement. There isn’t a bug around this issue, but it’s something you think should be added. Open a ticket, make your case, stay on top of it, and be prepared to wait. Don’t avoid voicing an opinion. Don’t avoid creating a patch as a proof of concept.
4. X is broken and needs to be overhauled. You’re an addict now. And in reality, this is a combination of the first 3 types. Be prepared for the long haul as this isn’t a one day deal. Commit to being involved with the conversation for months and years. In the process, you’ll come across plenty of the first 3 on this list to keep you in the release notes. 😉

Of course, patches very much aren’t everything. I only lead with that because code is usually my focus. Commenting, testing, and sorting tickets make up the majority of work done when making progress as a community.

Types of Trac activity in Jeremy’s perceived order of difficulty:

1. Comment. Go to Trac, find a ticket, and voice your thoughts. This can be a “+1” or a “-1” or an epic tale of how the extra padding on a button feels weird.
2. Testing. Patches are only as good as the testing that was done on them. So many things often end up stuck only because more testing is needed. Go through the process of downloading and applying the patch to trunk. Ask for help if you need it. And test!
3. Sorting. Over time, you’ll become more and more familiar with how Trac is organized. As things are created, they need to be filed with proper components and milestones and such. After commenting and participating you’ll wake up one day to find that you’ve been given Bug Gardener status. Now you can help in the due diligence of sorting tickets. Woot!

And one more list. No perceived order of difficulty.

1. Cultural and language hurdles. Communication via text can be tough. It’s so hard to convey emotion and so easy to read into things that aren’t things at all. Read anything you come across as if it was said with a pleasant tone. Nuances in the English language are hard enough for native speakers and we’re a worldwide community!
2. Uncommitted patches are not a waste of time. I would be surprised if the number of uncommitted patches on Trac doesn’t exceed the number of committed patches ten fold. Each one of these is progress toward a communal goal—make WordPress better. Submitting a patch and not having it accepted is not a waste of time.
3. Embracing backward compatibility. WordPress is backward compatible and this can be tough. It’s often much easier to create a patch that solves “my problem” without having to worry about how it affects 20% of the Internet. We don’t have the luxury of tossing those in. From time to time a patch could be held back because there is no immediate approach that can guarantee existing sites don’t break. Submitting this patch was not a waste of time, even if a wait is required.

So that’s that. Jeremy’s path to becoming and guide to being a WordPress core contributor.

There’s a gaggle of friendly WordPress folk waiting in IRC and on Trac to help you jump in when you’re ready. Get on it!