Contributing
24 May 2015
Since starting this 365 day adventure, I have done a mixture of contributing to my own projects and to others. At the on-set, I made an assumption that it would be an even distribution of commits between my own projects and existing ones. However, this proved much harder than I originally thought. After a sizable amount of effort, I did find a few projects to contribute to. 28 days into this endeavor and seems like I might actually be able to accomplish my goal.
One of the existing projects, pluck to hash, was a very young project when I found it. The project was released without any test coverage so I attempted to rectify that. Thankfully my pull request was accepted! It felt great to finally contribute to a project that wasn’t my own. I also learned a few things by doing so.
The first important learning from making a contribution was understanding that the caliber of contributors to open source software was not vastly superior to “normal” software engineers. I had previously thought of people who wrote open source libraries to be some sort of battle-tested, hardened, bug-resistant demi-gods sent here from Krypton in order to write code for us mortals. This was a very debilitating thought. For years it was a wall between me and open source software development. I didn’t even entertain the idea of surpassing that wall and inevitably gave up on making meaningful contributions. Alright, that is probably a little dramatic but I think it makes my point for me. It was intimidating to contribute! Then, like a breath of fresh air, my pull request was accepted and these preconceptions vanished. It was awesome. It was super awesome (and objectively I didn’t even do that much).
A second learning from finding projects to contribute to was how to find them. It seems like an important thing to know, right? There are a few tools one can use to find projects that are ripe for the commit-in. Using the explore function on Github, you can find the top trending projects on a per language basis. This process is how I found the puck to hash gem and decided to contribute. A big difference between the pluck to hash repository and others is the fact that pluck to hash did not have any open issues. Contributing to a repository with no open issues could be considered risky. After all, if a project has open issues then at least some work is welcome and expected. A project with no open issues can not be assumed to want, need, or accept contributions. Luckily for me, the pluck to hash maintainer was open to my additions.
A great resource for finding projects ordered by issue count is CodeTriage. CodeTriage does a great job of indexing projects hosted on Github in descending order of their open issues. Finding the right projects to contribute to is hard, but with CodeTriage and the built in issue trackers in Github, contributing to repositories that matter to you and to others is achievable.
Use these resources and start making some contributions of your own.