If you are not already aware, WordPress releases its own default theme once a year that is packaged with the software from there on out (so far, at least). A few days ago, the announcement was made revealing the new Twenty Sixteen theme.
I love the theme. It’s a solid foundation to use as a reference or even a starter theme for your own projects. There have been scattered comments about its design but if you’re anything like me, design is not the focus here.
Twenty Sixteen reminds me of Twenty Twelve in that I can see myself poking around its code as I build my own themes. I wouldn’t be surprised if I even customized it a bit and ran on one of my sites. In fact, my Enterprise theme was inspired by Twenty Twelve.
Your Contributions to Twenty Sixteen
I’m not here to talk about the fine details of Twenty Sixteen. Instead, I want to talk about your role in the development of the theme itself.
For what I believe to be the first time ever, the default theme is on GitHub as a repo that anyone can contribute to by opening issues, submitting pull requests, or even just testing and providing feedback.
This collaborative approach isn’t anything new. But with the move to GitHub, I suspect that a lot more developers and users will feel comfortable being part of the development process. For many developers in the WordPress space, including myself, this is a great way to get involved with contributing to WordPress.
Collaborating and Contributing
This is not the article for teaching GitHub workflows so I won’t go down that path. I will, however, point you in the right direction if you are looking to “git” involved (I’m sorry).
Start with an Issue
On GitHub repos, Issues are a way to manage sidebar information about the repo. They’re used to report bugs, discuss ideas, and much more.
After you’ve downloaded Twenty Sixteen and you have feedback for the community, you should start with visiting the issues page.
Notice I did not say you should create an issue. Reason being, you want to make sure no one has already discussed your topic. Browse through the open and closed issues before starting one of your own. Even if someone has already started a similar issue, you may still be able to provide important feedback to move things along.
After browsing the issues, if you notice that no one has started the conversation you’d like to have, you can now open your own issue and tell the community what’s on your mind.
You need to go through this process whether you plan to be the one fixing the problem or not. When you’re working on a repo that several other developers and users are working on, the last thing the community needs is for the environment to be flooded with duplicate content. So as a first step, regardless of what will follow, always start with an issue to establish the home base for a particular topic.
Take Action to Address the Issue
What comes next depends on what you had in mind when you discovered the problem. To be perfectly clear here, you do not have to be the one to handle an issue. If you’ve addressed a legit concern, that action in and of itself is a solid contribution that could lead to making the theme better than it was before. So even if you find a bug that you do not know how to fix, still report the bug.
If you do happen to open an issue that you do not intend to take care of, your assistance may still be needed for a number of reasons.
Some issues lead to long discussions about expected behavior and/or possible solutions. Your feedback is always valuable so do not run away from the issue once it’s opened. You may even be the one to test a patch that someone else submits, which is just as important as the patch itself.
However, some of you will plan to submit patches yourselves, which is outstanding. If that’s the case, while there’s no rulebook saying you must do it immediately after opening an issue, I would highly advise you to.
Some issues are straight to the point, like typos or obvious bugs in the code. For these, posting an issue will oftentimes lead to several contributors trying to take care of the problem. If your issue hangs around for too long without a solution, chances are someone else will provide one.
Submitting a Patch
If you find a problem you’d like to fix, the first thing to do is fork the repo. What this does is give you a copy of the repo as it stands at that very moment. This fork will now belong to you and can be cloned to your local machine for development.
How you choose to manage branches on your forked repo is up to you. But the simple fact that your repo is separate from the original repo is what matters here.
I tend to find issues on my own local machine (cloned from my forked repo), fix and test them locally, and then push the changes to my forked repo.
At that point, I open a new issue on the original repo followed immediately by a pull request from my forked repo to the master branch of the original repo. I make sure this happens fast enough so that my issue doesn’t linger and I’ve had the maximum amount of time to understand the problem at hand before bringing it to the community.
I don’t do it this way to be selfish and keep patches to myself, but instead to prevent others from doing the same work I’m already doing, which is a waste of everyone’s time.
Even more, fixing an issue locally before opening an issue can sometimes reveal a deeper problem than what you would have described in the issue or maybe that there was no issue at all.
Being hands-on before starting the conversation is key.
Once your issue is opened and your pull request is submitted, you wait patiently and with an open mind. I’ll be the first to tell you that there are things you know, things you don’t know, and things you don’t know that you don’t know. The third category is what you will learn the most from as you collaborate with other talented developers.
At this point, I’d say at least 25% of pull requests I’ve ever submitted have been rejected because of an oversight on my part. I’ve learned a lot from those experiences, though, and what is now 25% used to be upwards of 50%.
Just remember that the goal is to improve the software, not earn cool points.
Get Involved with Twenty Sixteen
That’s enough talking. Let’s stand behind WordPress’ move to collaborating with the community through GitHub. It’s a new path and one I’d like to see us stick with.
If you are not quite sure what to do just yet, that’s okay. Start reading through Twenty Sixteen’s issues and be part of the conversation where needed. Eventually, an opportunity will fall into your lap. Trust me.
Happy coding. 🙂