How I became a Rails contributor

This is my personal journey on becoming a Rails Contributor. This is a less technical blog. The technical version can be found here.

One day at work I found a problem with a Rails query while working on our internal filtering gem.

I quickly found an existing issue on the rails repository. I thought, "Great! The Rails maintainers know about it so it's likely being fixed soon". But then I looked at when the issue was created. 2021. It was three years old. So much for it being fixed soon 🤷🏻‍♂️. I looked into the issue a bit more and learned that it was introduced after a "caching" layer was added to ActiveRecord query generation logic. There were multiple comments on the issue but only one comment from @oneiros had a suggested solution.

That was it. I went back to work and didn't think any more of the issue. If it was an issue for three years, it likely wasn't an easy fix and wasn't a high priority for any maintainer. I couldn't fix it. I was just a normal dev.

During a weekly sync with my manager, he suggested that I should attempt to fix the issue. We have personal development time at Fleetio and he thought this would be a good use of that time. Even if I couldn't fix it, I would still be learning and growing my dev skills. I agreed, so the following Friday I decided to try and fix this bug.

My first step was to figure out how to contribute to Rails. Luckily there is great documentation for that. I followed the steps to use the VS Code remote containers plugin. This was my first time working with the new rails .devcontainer setup but it was a lot easier than I expected. Once I had the Rails environment set up, I ran the ActiveRecord specs. (Rails is split up into multiple gems, and this bug was within the active_record). The specs passed. I successfully had the dev environment set up.

All of this set up took around 15 minutes. A lot faster than it could have if I tried to set up everything without the dev container.

Now that I had the environment set up, I needed to generate a failing spec. This proved a lot harder than I expected. The bug was tough to reproduce. Eventually, after about an hour, I was able to create the failing spec.

Now I could actually start to work on the bug!

I used the comment from the issue as a starting point. I just copied the fix and my test case passed! 🎉 I quickly created a PR to Rails. This was a mistake. I got excited and rushed the implementation. But I made the mistake of not running the rest of the test suite. While my problem was fixed, the original change spec was failing. All I did was "revert" the original change.

Since the easy fix didn't work, now I actually had to try. I spent a few hours trying different approaches that I won't get into in this post. See this blog if you want more. Finally, I found a solution that had my spec and the original change spec both passing! 🎉 I created a second PR to Rails and called it a day.

The following Monday I checked on the PR and the build specs were failing. I thought "How could this happen? It ran fine locally!". It turns out, I wrote my spec in a way that failed if MySql was used as the database. MySql and Postgres/SqlLite use different quotation marks/styles. I quickly updated my tests, ran the entire test suite with each database option, and submitted yet another PR to Rails.

After three days of no feedback, my PR was merged! Two months later, it was released as part of Rails v7.1.5.

Key takeaways

• Being a contributor to an open source project can be intimidating. Don't let that stop you!
• Understand the problem completely before attempting to fix it.
• Be patient and run all tests before creating a PR.