I’ve spoken in the past about how easy it is to contribute to WordPress, whether editing videos, writing documentation or one of many different things that don’t require you to be a development whiz.

But what if it’s the core WordPress product that you do want to help with but you find the thought of it too hard? Well, I’m going to share few simple ways to get involved from zero to limited required development skills.

A note on named contributors

You’ll notice that I talk about whether you get listed as a contributor during a release. To me, this isn’t important but I accept that for others it is, and may even be a driving force to get involved with core (involvement in other areas of WordPress doesn’t lead to such public recognition).

Contributors are shown in WordPress using the following API result…

http://api.wordpress.org/core/credits/1.1/?version={$version}&locale={$locale}

So, for WordPress 6.1, and the UK English locale, the link is…

http://api.wordpress.org/core/credits/1.1/?version=6.1&locale=en_GB

I’ll mention this again in a bit, but the locale is there because contributors are different in locales, based on translations.

Method 1: Raise issues

Found a bug in WordPress? Report it via Trac – providing as much as you can, including recreation steps and screenshots. A kindly developer is likely to step in, fix it and then add you as a contributor to whichever version of WordPress it gets released in.

Just bear in mind that just because you’ve found a bug means that everybody will want to immediately fix it or, even if they do, that it will be released straight away. If your issue is low priority and the fix is complex, it may be sometime (or never) before anybody tackles it.

My recommendation would be to report it but then follow it, making sure to answer any questions or provide anything else given. The developers will move it forward appropriately – if not at the pace you’d expect, then do try to explain why you think otherwise (it may be that some of the context has been missed). Otherwise, move on.

Here’s an example of where I did this – I raised an issue with the use of the word “nonce”. A discussion ensued, which initially was push-back, but eventually a change was made and I was listed as a contributor.

Method 2: Get involved in conversations

You know those Trac tickets I mentioned above? You don’t have to just raise the to get actively involved – just getting involved in conversations in them is equally valuable.

For example, years ago, I spotted an issue with WordPress transients. However, somebody else had already raised the issue but the ticket had stalled, progress wise. I added additional context and then got involved with the ensuing conversation. When changes were made, I was listed as a contributor. Again, without having to write a line of code.

Method 3: Translation

This is one I’ve mentioned before, but all WordPress releases need translating into any and all languages. Jump into translation, find a language you know and help the core translation team.

If your expect your hard work to mean a mention in the list of contributors, just bear in mind that this may happen, but it will be locale specific. So, if you helped translate into Spanish, you’ll only be listed as a contributor on sites that are set to this language. My belief is that validators (Global Translation Editors) get photos on the contributor pages, while translators get just your name.

It’s also worth noting that although language translations for official themes are also very much needed, getting involved with these doesn’t lead to a listing as a contributor.

Method 4: Changing the code

It’s even possible to do this without making changes to code (I’ll explain, don’t worry) but making minor changes to the code can be done without having to jump through a lot of hoops.

You first of all need to understand what the core team need – diff files. These show before/after differences between the files you’ve changed. This is because the version of WordPress that you may change and test against may be quite different to the version that your code change ends up in. So, they just want to know what you changed and where.

I mentioned too that you can change the code without, well, changing the code. And, that’s comments. I recently made a lot of code comment changes to WordPress to remove some exclusionary language that had been used. No code technically changed but it still needed to go through this process.

So, providing a diff the easy way…

1. In Github, make a fork of the official WordPress repo
2. Make your changes in your forked version
3. Test your changes appropriately
4. Now, bring up a PR of the changes
5. Head to the URL at the top and add, to the end, .diff
6. The Pull Request should now change to a plain-text .diff
7. Download this and attach to your Trac ticket

Voila. One Trac ticket, now with a .diff of all the work you’ve put in.

Indeed, if it’s a small change I’d recommend only putting in the Trac ticket until you have the .diff ready, as otherwise someone else may beat you to it (This happened to me once – the change was so minor that before I knew it, someone from the release team made the change themself and added it to the next release).