How to Contribute to an Open Source Project

So you've found that sweet open source project that you want to get involved with. Now what? The first thing you should do is look for that project's guide on how to get started with contributing. Often, this will be in a file called CONTRIBUTING, or on the project's wiki. These guides will often explain everything you need to know about how the project management team expects people to work. Things often covered include how to build and test the project, how to submit patches, and what communication channels to pay attention to. Node.js has a great contributing guide if you'd like to see an example of what these files often contain.

If the project you'd like to contribute to doesn't have such a guide, it's not that big of a deal. It probably just means that the project hasn't seen that many external contributors, or that it just uses a very standard workflow. If the project is hosted on GitHub or BitBucket, chances are the project uses GitHub Flow for code contributions. This guide by GitHub has a pretty good description of how the process works. The project probably uses GitHub Issues as an issue tracker, which is a very easy to use system.

Alright, so you've read the guide, and figured out how the project works, and you're ready to start making a difference. Where do you start? The easiest way to join the community is by filing and commenting on issues. The first step of fixing a problem is making sure it's known. Filing good, descriptive issues is extremely helpful to the project maintainers, as it tells them where they should be focusing their efforts. Keeping track of and reviewing pull requests is another great way to get involved. It helps you stay up to date with what's happening with the project, and who knows, maybe you'll spot the next project-breaking typo that slipped past everyone else.

Another great way to ease your way into a project is by doing some repository cleanup. This can include updating documentation, making sure code fits the project's standards, or making the readme prettier. All of these are tasks that are very important, but often project contributors won't take the time to do them themselves.

Once you've settled into working with the project's community, it may finally be time to start writing code. This can be a daunting task; submitting your first patch is definitely a scary thing to undertake. When deciding what to tackle first, it's probably best to start with something relatively simple that has already been documented to increase your chances of having the patch accepted. The simple the changes, and the easier your code is to read, the more likely it is that someone will review it quickly, and merge it. The patch is also more likely to be accepted if it solves an issue that people are already looking out for.