Coming into picking a project to contribute to I was not picky and just wanted to contribute to a project I had used. This led me to look through the gemfile on some of my previous Rails projects and checking out the gemfile. Since I'm most comfortable writing and reading code in Ruby, gems seemed like the right place to start looking for open source projects for contributing. I looked through my gemfile and picked three of my favorite gems, rspec-rails, shoulda-matchers, and faraday. After reviewing some of the criteria spelled out in the Turing guidelines, I picked up a few more important considerations. I started looking at how recently the code had been updated, size of the project, clarity of the contributing.md, and conversations happening on the issues section in Github. Further narrowing down using these three criteria I decided I wanted to contribute to the shoulda-matchers gem.
My first step was to clone the shoulda-matchers repository and follow the steps on their contributing.md to get the test suite running. From there I was immediately overwhelmed with trying to understand what was happening. Despite how easy the gem is to use, it was surprisingly difficult to understand. Traversing the logic through all the different classes and modules seemed nearly impossible. Instead of wasting time trying to understand everything at once I chose a test file and set out to understand those tests. The tests were easy to follow and from there I dove back into the code using the tests as a tool. I would edit lines of code or pry into the files to follow the logic through the code base from the beginning of the test to the end. After repeating the process for three tests I finally felt like I had a reasonable understanding of the code base and could start to think about making some contributions.
Per the project recommendation I started off working to confirm / contradict bug reports from the github issues. This meant that I had to go back into some of my own previous rails projects and simulate the situation setup in the bug report to try to reproduce the bug. Not only was it satisfying to reproduce the bug but it also really helped me to continue to learn more about the code and the community of people maintaining it. For the three bugs I investigated, I was able to confirm all three and wrote thorough comments explaining how I reproduced the bug. Hopefully with the bugs confirmed the community can move forward confidently to work on resolving them. Check out the three bugs I confirmed and the commenets I left here:
- Incorrect message matching
- Validate length of with numericality
- Validate confirmation of with integer columns
After confirming the three bug reports I felt ready to try to fix one of the bugs. I chose to work on the validate_confirmation_of with integer columns since it seemed the most accessible. I started by writing a few tests to try to achieve the same behavior described in the bug report. Once I had written the happy and sad path tests for the scenario described in the bug I began writing code. I added functionality for the type to be passed through to the :attribute_to_confirm on the model. Then I used an if statement to handle strings in one way and integers in a different way. One struggle I had was how to cater the error message (in the sad path test) to the type off the :attribute_to_confirm on the model. It ultimately took fewer lines of code than I expected to get both tests to pass. Check out the branch and the corresponding the pull request
Going forward I am looking to stay active on the shoulda-matchers project to see what comments and suggestions my bug confirmations and pull request spur. From experience working on the pivotal tracker gem, there will be plenty of comments and feedback before PR would be ready to merge. Staying diligent in my communication with the contributors to the gem is probably the best chance that I would have to continue to learn from the community and hopefully contribute in some way.