Why You Shouldn’t Be Worried About Screwing Up When Contributing To WordPress

In the WordPress 3.9 development chat that was held on Wednesday, January 15th, a number of topics were discussed ranging from features that people are working on to announcing the date for the release of WordPress 3.9. One of the most interesting topics, however, centered around first time contributors using trac to create tickets and patches.

Last week, one of the improvements to trac was the addition of the “good-first-bug” tag. This tag will be used to identify tickets that are good starting points for new contributors. In my opinion, this is one of the most important changes to trac we have seen in a long time. Here’s why.

WCSF Contributor Day
WCSF Contributor Day

Near the end of the meeting, a number of people shared their stories of how they contributed to WordPress for the first time. Some people used the contributor day at WordCamp San Francisco to create their first patch or ticket while another did the same at WordCamp Orlando. When I attended the WordCamp San Francisco contributor day 2013, I was able to create a ticket for a longstanding issue I’ve had with the WordPress Media Library. Without the help of Mika Epstein as a mentor, I wouldn’t have been comfortable enough to create the ticket.

Trac Intimidation

The Intimidation Factor

I was asked by Andrew Nacin why I felt trac was intimidating. I consider trac to be a place where all the magic happens. It’s where you need to know diff files, ticket numbers, code, etc. It’s not something a common end-user would be comfortable in navigating. To me, trac is an entirely new world that I’ve always been too nervous to enter. I don’t think I’m alone in fearing trac or being intimated by it and thus, not contributing to WordPress in that way.

Good First Bug
photo credit: gui.tavarescc

This is why I think the “good-first-bug” tag is so important. When someone new to trac picks those tickets to work on as their first, the expectation is for mistakes to happen. If a new contributor screws up a diff file or does something else wrong, it will be ok because it’s expected behavior. It takes a lot of stress off of the new contributor and creates a learning environment without the fear of screwing things up for everyone else.

They’re Not Angry, I Just Think They Might Be

I was then asked where the line of thinking comes from that results in me thinking that a developer might be “angry”? Are people giving off that impression? I don’t think it’s the impression those participating on trac are giving off but rather, an unnecessary fear I have. The fear in trac is doing something wrong, angering a developer, wasting their time, and making mistakes. I’ve never seen a public trac discussion where developers are yelling at newcomers for making dumb mistakes. Just the possibility of making established contributors angry is enough to prevent me from participating in that community. It’s an unnecessary tension that I think a lot of people feel.

Plenty Of People To Guide Me

Guide Me Compass

Thankfully, I was reassured from multiple people that I don’t need to feel the way I do and that there are plenty of people willing to stop what they’re doing to help guide me in the right direction. One of them was Andrew Nacin, one of the lead developers for WordPress.

Please never worry about angering a developer or doing something wrong or wasting someone’s time. I get angry at developers who get angry with contributors and if you ever do get the impression you’ve annoyed someone or are doing something wrong, anyone is always welcome to ping me privately and I’m happy to A) talk to you about it and walk you through it, and B) privately talk to any contributors who *are* causing problems.

What Andrew states is a sentiment that most in the WordPress Development IRC channel share. The fears that I have of screwing up are a large reason why I’m a huge fan of one-to-one mentorship. An individual who can help me through the ticket/patch process without fear of looking like a fool in front of established contributors. While there is an initiative to get a list of mentors put together, it will be awhile before something official is put in place.

WPMentor Featured Image

What I’ve seen at contributor days at WordCamps proves to me that a WordPress mentorship program would substantially increase the amount of first time contributors. It’s not about having my hand-held as I go through the process but rather, helping to build my confidence level to a point where I’m comfortable enough to go through the process on my own. Helen brought up a great point in the conversation. If you don’t have access to commit code to the core of WordPress that millions of people will use, then there should be no reason to fear the actions of creating tickets or submitting patches.

Contributing To WordPress For The First Time

When I contributed a patch to WordPress for the first time, it was an exhilarating experience. Talk about an adrenaline rush! After I saw my name in the credits portion to help make WordPress 3.8 a reality, I wanted to learn everything there was to know about PHP and contribute to WordPress full-time. Of course, reality soon sunk in but it was an awesome experience. My hope is that the tickets labeled with the tag “good-first-bug” are blessed so when a person uses them to get their first patch into core, they will experience the same adrenaline rush I did and consider becoming a regular patch contributor to WordPress.

You’ll Need Thick Skin

You'll Need Thick Skin
photo credit: uberzombiecc

Not every patch makes it to core. Some of them are discarded and when it comes to using trac to contribute, you’ll need a thick skin and be able to accept defeat. However, those experiences build character and just because a patch is denied, doesn’t mean it’s game over. It’s important to note that while most of this article is dedicated to contributing to WordPress through trac, there are many other ways to contribute. As Helen noted in the conversation:

There are things beyond patches that are extremely valuable, and in some cases even more valuable. Great bug reports, reproducing elusive bugs, testing patches, refreshing patches, commenting on tickets so people don’t feel like they’re left hanging, etc.

So far, the best guide I’ve seen on the topic of contributing to WordPress was published by Siobhan McKeown. While it’s from May of 2013, it does an excellent job of showcasing all of the different parts of the project that people can contribute to.


My main take away from the WordPress developers chat is that my fear of navigating trac and contributing to WordPress through code is unwarranted. There are plenty of people willing to stop on a dime and help me through the process. All I need to do is ask. I also learned that getting new people to contribute through trac has become one of the top priorities for WordPress core developers.

So far, trac has undergone a number of changes that reflect that train of thought and there are more to come. Thanks to improvements like the addition of the “good-first-bug”, trac doesn’t have to be such an intimidating place to begin contributing to WordPress through code. Trac is not a fraternity, it’s not a place where only the elite of WordPress programmers reside. Trac is just a tool to help improve WordPress, nothing more. I contributed to the core of WordPress and you can too!

Credit for the title of this post goes to shelob9 also known as Josh Pollock from the WordPress development chat.


16 responses to “Why You Shouldn’t Be Worried About Screwing Up When Contributing To WordPress”

  1. Everything you described as reasons you weren’t contributing are exactly my reasons, and I work for a world class WordPress Development company with like 20 other contributors and even a core committer (Helen). I wasn’t aware of the “good-first-bug” tag, though, so that gives me some hope that I might be able to try it out. It really helps to know I’m not alone in my fears; thanks for sharing your thoughts!

    • Actually, I should be thanking you for helping to confirm I’m not crazy and that my fears are shared by someone else. The Good First Bug tag is only a week or two old. I don’t know if any tickets are actually tagged with that label just yet.

      There was also discussion on how a ticket or bug would qualify for that tag. Obviously, what’s an easy good first bug for someone will be difficult for someone else. However, I think the core devs will do a good job labeling bugs with that tag if they are specific, don’t touch a lot of components and are not deep into core.

  2. Contributing to WordPress would be so much easier if they moved away from Subversion/Trac over to Git/Github.

  3. I also saw a great new footnote on Trac this morning on #26849

    “Make sure evilpepe receives a warm welcome — it᾿s their first bug report!”

  4. You’re not alone, I’ve had the same thoughts, feelings and perceived experiences. I’ve found a niche of sorts but it can still be intimidating. I don’t mind being new, nor do I mind writing bad code and having it criticized (I welcome it, in fact…how else to get better?) but I’ve found at times it’s easier to just back off than risk comments I don’t know how to interpret. +1 to needing a thick skin…I’m not quite there yet.

  5. So well-written Jeffr0. I’ve only recently been testing the waters of Trac and you’ve very accurately detailed my own first impressions and insecurities.

    I have never met a WordPress developer who did not want to contribute; it always comes down to either lack of time or not knowing how.

    The latter is something that can be fixed, however, and it’s great to see so many pros like Helen and Nacin making this a priority!

  6. OK, I made my first comment in trac regarding the twitter api blowing up embedding.

    I chose for the status, “works for me” since that’s exactly what the patch did.
    Little did I know that closed the ticket??
    So yes, someone did get pissed off at me, but to hell with that! LOL
    Why does “works for me” close the ticket?

    Anyway Mr Nacin came along afterwards and did indeed close the ticket after a few bits of house keeping.

    • Maybe a link to an FAQ would have been helpful, should one be added you think?

      Basically all of those ‘status’ messages revolve around the details of what, why and where code will actually be merged into the main WordPress codebase, a ticket typically won’t be closed until the code is ‘committed’ into WordPress’ core codebase.

      I’m quite sure @ocean90 wasn’t pissed off at you, he was just trying to give a tip on what ‘worksforme’ actually means.

      Nacin only closed the ticket after the code had been ‘committed’ into the main codebase (See comments 10, 11 & 12) where you see eg “In 26967:” they link to actual code changes that were made.

      Here is that definition in full from the ‘Trac Handbook’


      “worksforme: The bug reported in the ticket cannot be reproduced. Sometimes, an existing plugin, hook, or feature may render the ticket moot, so the ticket can be closed without further action.”

      Hopefully this clears things up for you a little as to the context of that tickets ‘workflow’ and I’m quite sure no one there meant you any harm, and though it wasn’t explicitly added as a comment the ’19 watchers’ on that ticket most likely found your comment “the problem and this fix now works” helpful, as I know I did. :)

      • Thanks. I am usually energetic about researching something, but frankly, at the time, I was very happy the patch worked so “worksforme” felt so right as my chosen status. I had no idea it was referring to the pre-patch state.

  7. With an article this compelling, what am I waiting for to make my contribution? *runs off* *returns* Thanks Jeff! *runs off again*


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: