in Editorial, Open-Source

Contributing on GitHub for Dummies

I’m naturally an idiot so this took me a while to get a good understanding of. Even now I still mess it up, but I feel like I can at least grasp the basic requirements of being a good contributor on GitHub – so let me share them with you!

Coding in public is pretty scary. Not just for contributors, but for project maintainers too. Everything is being watched and recorded and saved forever – there’s no (easy) erasing of mistakes, which leads to a lot of pressure on everyone involved.

So take a step back, realise that this is open-source software, and relax. GitHub is the proverbial playground for an open-source project, where things can discussed and tried – don’t be afraid!

Start with an issue

I feel like everything should at least start with the creation of an issue, as it allows everyone that’s following the project to stay up to date and for a discussion to take place if need be. It also serves to be a useful bit of history if needed later – rather than just a PR (pull request) with no story behind it.


An issue with a PR is better

This is definitely true but don’t let it hold you back from opening an issue. If you really feel strongly about an issue, make the PR that solves it. It will help your case more, as there’s no more work involved for the project maintainer if they do agree with you.

Branches are better

I used to get so scared about making a branch. Honestly I just didn’t understand what it was, but when you do, you’ll use them too.

Before you start working on an issue, fork the project and create a branch named something like patch-5, where 5 is the issue number you’re working on. It could be something else, but this is often the easiest way to maintain all of your branches.

Then when you’re ready to make that PR we spoke about before, make it from the branch you created. That way, you can keep working in other branches on fixes for other issues, while the PR you just made get discussed.

Give value – it’s not a race

I love seeing people contribute, especially for their first time. However, it’s not a race. It’s not a competition. If you don’t have anything of value to offer, don’t just make a PR so you can get your name on the contributors list. Code formatting PRs are mostly acceptable but if you’re going to add some more spacing so that it’s aligned properly, it’s probably better you don’t.

Don’t be selfish

Last one, don’t be a selfish contributor. That probably sounds crazy as the act of contributing to begin with is likely an unselfish act, but don’t just open your issue and run away. Chime in on other issues, see if you can close other bugs! No one will hate you if you don’t, but if you’re already there, try to help out! 🙂


Write a Comment



  • How to Create WooCommerce Custom Redirects - Bryce Adams

    […] Contributing on GitHub for Dummies […]

  • What WordPress means to me - Hugh Lashbrooke

    […] sharing it through plugins will force you to improve very quickly), I’ve learnt a lot about contributing to open source projects, and through organising WordCamps and other meetups I have learnt important […]