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.
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.
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.
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
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.
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
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.
Conclusion:
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.
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!