My last post was about the things I’ve been learning, in order to be a good open source contributor. One major thing I left out about preparing to contribute a project is to read the Issues section on GitHub! The more time you spend using GitHub, the more obvious this becomes – it’s where a lot of the project coordination occurs for open source projects. For people new to open source, like me, it’s especially important to read the issues that are there.
There are a lot of good reasons to read the issues. Unless you’re an avid user of the software being developed, or are already pretty invested in it, you probably have no idea where to start, as far as contributing. The issues are often going to frame nicely what people want to have happen, or what bugs need to be fixed, and can often even give you a better vision of the project overall – where it is now – and where people want it to be.
Another reason is, there may be bugs to be fixed, or features to be added, that people have already discussed in depth, or recently volunteered to fix. Sometimes people volunteer, and never get around to things, but it’s still good to have an idea so you don’t do a bunch of work – only to find that it’s redundant by the time you can submit a pull request. Sometimes issues are flagged, asking for volunteers or suggestions.
One of the other great reasons to read issues is that it can be the easiest way to start contributing! Whether you create an issue on your own, or reply to existing one’s, you can often provide helpful suggestions, or ask questions that help narrow down the path for next steps in development. I’m learning more and more that software development is often not really specifically about code. A lot of it is decision-making and collaboration.
For people looking into contributing to open source – it often makes no sense to “barge” into a project and throw code at it before you really know what’s going on. Get involved in the conversation! If the Issues tab is dead, you can still glean info from the readme, or contact the owner of the repository, or active contributors – or create an issue yourself! I’m enjoying learning more about open source development, and will write more about it soon.