WordPress 3.5 was the first release that I’ve had any meaningful involvement in as a contributor. Before this, I’d spent time lurking around in IRC and browsing around tickets in Trac, but with no real purpose or intention. With 3.5, I really wanted to try and see what I could contribute.
The result? Well, if you look real close in the screen below, you’ll see my name in the bright lights near the bottom. Seeing my name on this page was extremely exciting.
But then the guilt
Truthfully, although my name does magically appear on the credits page, I must confess that I did very close to nothing to help out with the development and release of WordPress 3.5. Very early on, I participated in some discussions on a new look for the Welcome screen, I very briefly popped in to talk about the “Page on front” workflow, I suggested that icons might be nice on the welcome panel, and I thought that a border might be nice under h2 tags in the Twenty Twelve theme. Like I said, in the scope of this thing, I contributed almost nothing.
Why didn’t I do more?
There are two main answers here: A) I just didn’t. Simple as that. And, B) the technical reasons.
Before I say anything about B), I want to make it absolutely clear that I did not do all I could to overcome the technical hurdles I faced when trying to contribute. I didn’t read as much as I should have, I didn’t reach out enough when I ran into issues or got confused, I didn’t develop a deep enough understanding of Trac, I didn’t step up and claim ownership of issues I could actually help fix. I want to make that crystal clear that I personally did not do enough to overcome the issues I ran into. Ok, so onto B: the technical issues.
Technical Overhead
Contributing to WordPress comes with a lot of overhead. Knowing how to setup a local install of the latest version, keeping that up to date, creating patches, applying patches, and I haven’t even mentioned Trac yet. A lot of the issues I had have already been pointed out in the notes from the “Engaging/Retaining New Community Devs” at this year’s community summit, but I want to
specifically go through a few of the issues/questions I had here:
1. I use Git. Is that ok? Should I just learn svn already? Update: Scribu posted a great, concise how-to. Sounds like you’ll never need svn again.
2. Making patches. Helen very kindly walked me through the process of making a patch. Very soon after, however, with no practice, I’d forgotten the basic steps
3. Keeping my repo in sync. So, I clone WordPress from Github per Mark Jaquith’s instructions and start working on a ticket. As soon as touch a single line of code, my repo is out of step. What do I do now? I’m positive I’m not doing this right, but I don’t the right way to do it.
4. #Trac. How people can find and sort tickets to issues is just beyond me. I find Trac to be almost a complete mystery. How do I find open tickets? How can I get a list of tickets that I might be able to work on?
5. #wordpress-dev. The folks who inhabit #wordpress-dev on IRC are extremely knowledgeable and helpful. They’re also very busy and focused. This definitely isn’t the place for questions like “how do I make a patch” when we’re right in the middle of heavy development. But outside of there, I don’t really know where else to ask that question.
6. Foraging for resources. I wish there was one good, comprehensive guide to contributing that brought you through all the steps. Everything from cloning the repo, making changes and not ‘breaking’ the repo, searching Trac for a ticket, creating/applying a patch, etc, etc. There are a lot of great resources out there, but they’re scattered around and sometimes not easy to find.
A few ideas
I can’t just create a list of problems without suggesting some ideas to help fix them. Two things stand out for me as being potentially huge for new-comers like me:
1. Mentoring. The word mentoring is loaded, I know. It comes with connotations of a long, arduous and time-consuming process but it doesn’t need to be. My suggestion? Create a place where a mentor can help walk you through three tickets. That’s it. In the process of working through these three tickets, the mentor can teach the new person how to set up a local repo, create/apply patches, and give them the basics of Trac. I think three tickets would be more than enough to get someone started.
So…..the real question here is — where do we get these tickets?
2. Identifying/tagging ‘easy’ tickets. Early in the release development cycle, you see lots of “easy” tickets floating around Trac. I’ve seen some that require changing a single line of css! Tickets like this would make a perfect starting point for someone new. Here’s how it might work: A ticket would be tagged as “easy” or “beginner” and a mentor would assign it to their new student. Tagging a ticket with “beginner” would mean that an experienced person should leave the ticket alone until a new person has had a crack at it.
This process would really get to the root of my issues pretty fast. Having three easily solvable issues assigned to me, with the support of an experienced mentor would be huge.
A brief afterword
As I hope I’ve already made perfectly clear, many of the issues I encountered in the past few months could have been solved by simply trying harder and persisting more. That said, there really is a lot to learn, and the biggest part for me was finding something small and “easy” to learn with. As you would expect, as soon as a simple ticket shows up, someone has a patch created in a few minutes. I really think that leaving some of these easier issues in reserve for new-comers, and actually assigning them, would be extremely helpful. While I recognize that this would slow down development, I think it would really be worthwhile, at least early in the cycle, to have new-comers get their feet wet with actual tickets.