We should all contribute to WordPress. It’s personally rewarding, it helps you meet new people and develops new skills, and it also shows your commitment to the community and helps ensure that WordPress — the thing we use to make our livings in one way or another — continues to improve and grow.
Don’t contribute to WordPress in a way that leads to burnout, or isn’t likely to benefit you. Instead, contribute by doing what you are good at. That way you’re giving your best effort, getting better at what you do, and getting recognized for it.
Some people can structure their professional lives in a way where they can spend a lot of time giving back to WordPress. These people may take jobs that require they contribute to core development or feature plugins, or they may answer WordPress.org support threads, or do any of the other countless things you can do to give back to WordPress.
But contributing to WordPress doesn’t have to be a huge part of what you do to make a difference. The WordPress community is comprised of thousands of people, and small contributions add up.
I’m a developer and a technical blogger, so contributing to core or feature plugins as well as documentation is how I give back. I’m also way over-committed already and don’t have a ton of time to give. So, I want to share some ways I’ve been able to be a “causal contributor.”
The advice, which includes the easiest way I found for creating patches in core, is geared towards what I do. I encourage you to let this inspire you to find ways to give your time in a way that makes the most sense to you.
Writing Docs
I learn by figuring things out and writing about them. If you’re like me, you should be writing documentation and tutorials. Don’t let the fear that you are somehow unworthy or under qualified hold you back. We all have something to offer. In a community as large as WordPress that means we need multiple ways of teaching everything.
The WordPress documentation team always needs help. Most feature plugins could also use help with documentation.
Almost all documentation in WordPress can be contributed to through some interface or another. Complaining about a lack of documentation, instead of writing the missing docs is disobliging if you have the ability to fill in the knowledge gap you found.
Contributing To Core
As of when I’m writing this, I’ve had three acknowledgments of contributing to WordPress 4.4. They are all very minor. One was for a patch I wrote years ago, and the other two were merged very quickly. The core team is trying very hard to bring down the time tickets with patches sit on trac.
I wrote a complete tutorial on creating patches for WordPress core, including an introduction to trac last year. But, I find that whole process to be way too involved for making a minor change. It frustrated me, as I often make quick pull requests to other projects using GitHub’s editor.
But, then I figured out how to use GitHub’s editor to contribute to WordPress core. There is an official mirror of WordPress on GitHub. While you can’t submit a pull request there, you can use their editor to create a commit in your own branch and then generate a patch file or “diff” to upload to trac.
Simply make the commit using the web editor, or by pushing a change to your own fork through more traditional methods. Then navigate to the page for the commit in your fork on the site. For example, here is the link to a patch I created using GitHub’s web editor:
https://github.com/Shelob9/WordPress/commit/dfc91084a7cf0b1efd79c167ae25217d66274cba
That link can’t be submitted to trac. Trac needs a “diff” file, which is a representation of a patch, to show what has changed.
If you add “.diff” to the end, the link is a proper diff file. I copied that into a text file and uploaded it to trac here. My patch was merged in less than an hour. Your experience may vary. Still, for something that started as me complaining on Twitter to fixing an annoying inconsistency in software used by millions of sites is pretty gratifying.
Contributing to WordPress core is just one way to leave your stamp on WordPress.
It’s a little tricky to get used to SVN, the version control system WordPress uses, and trac, the issue tracking system. Both systems are far from perfect and are not something most WordPress developers are used to. Using GitHub the way I described is great for casual contributors, making small changes.
WP Engine’s Anthony Burchell gave a great presentation on contributing to WordPress at WordCamp Tampa this year from which I stole the notion of “causal contribution.” If you’re new to the process, his slides are a great reference that you should check out.
Feature Plugins
Contributing to core involves learning new tools that are not applicable to most of our daily lives as developers. Feature plugins are more accessible since most of them use GitHub, which greatly reduces the friction to contributing.
Feature plugins also have a smaller team, which means a new contributor is, relatively speaking, a much bigger boost to the project. You can have a bigger impact and endear yourself to the leaders of the project faster. If you’re aligning your contributions with what you want to do professionally, this can be a major bonus.
If you’re new to contributing to WordPress or you’re just starting out as a developer, finding a feature plugin that could use your skills in some way or another is a great way to learn from more experienced developers. Working with a smaller group of people makes it easier to meet new people, learn from them, and impress them with your skills.
My handful of relatively minor core commits looks impressive though it doesn’t make me an expert. However, the fact that I have 15 or so commits to the WordPress REST API, including contributing the sections of documentation relevant to my work and have given several WordCamp talks on it, in addition to writing a 64-page free eBook on the topic does allow me to sell myself as an expert to my potential clients.
Testing!
There are a ton of projects happening in WordPress, from changes in core, to feature plugins, to new sub-sites and resources on WordPress.org. All of them need testing, feedback, and suggestions.
Installing WordPress in your test environment using Git or SVN makes it easy to stay up to date with the latest WordPress changes. The WordPress Beta Tester plugin is also easy for staying on the bleeding edge. Testing WordPress allows you to find bugs that only pop-up in day-to-day use which you can then report on trac.
Most feature plugins are on GitHub, which makes it easy to download, install, and create an issue for any bugs discovered.
Being a WordPress beta tester doesn’t just help the community. It also helps you be aware of changes and how they affect you. There is no excuse for core updates to catch you by surprise since changes don’t actually happen in one big push, three times a year. They are actually a series of small, ongoing changes.
Conclusion
I love WordPress, you love WordPress, we all love WordPress. But WordPress is far from perfect and it never will be. The code base, the documentation, the feature plugins, the community — it’s all an ongoing project that will never really be complete.
Helping WordPress evolve is good for the community and it’s good for you. I don’t just mean that in abstract terms. When you’re looking to land a new client or find a new job, your contributions to WordPress core, feature plugins, or other ways you’ve helped the community should be part of your pitch.
Saying there is a problem in WordPress is fine. Complaining only gets us so far and there is so much to be gained personally and for the community by fixing what needs to be fixed, offering feedback when needed, and being patient with those who are able to give more time to do the more complicated work that takes longer.
5 Comments