Today, I had my first Pull Request merged into an Open Source project! This has been a long time goal of mine. This is often a goal for developers and it’s sometimes hard to find the right project and way to contribute. Here are some details around my story and the lessons you can take as you take your first steps into Open Source.
A couple years ago, when I first took interest in contributing to Open Source, I followed the guide in the First Contributions Repository to learn about the workflow. While it was a valuable high-level overview, I still felt uncomfortable interacting with a real project. Every once in awhile, I would scroll through the
issues tag on some random projects, but had trouble finding something that met that intersection between “interesting enough to do” and “within my ability.” Luckily, a couple of weeks ago, I found that in the Ray project. We started using this library at work, and I thought making a contribution would be a good way to get more familiar with the tool, its capabilities, and structure.
Tip 1: Find a way to contribute by monitoring Issues that are tagged as Good First Issues. Sure, you could propose a whole new feature to an Open Source Project, and if that’s your skill level, rock on. However for the rest of us plebeians, scroll through the issues. These are usually smaller feature ideas or bugs identified by other users. Often, the easier ones are tagged. When I scrolled through the
Ray issues, I found a feature request by one of the core developers. Currently, they provide yaml configuration files as a path to a location on disk. He also wanted to be able to provide a URL to lower the bar for new users following his tutorials. So… modifying command line arguments to a python script and doing some web request work? I could do that!
Tip 2: You’re more likely to be able to contribute to younger projects. Previously, most of the code bases that I’d researched contributing to were big names like
scikit-learn. When I scrolled through the issues listed in those projects, most of the
good first issues were related to documentation (which, while necessary, I just had very little interest in).
Ray is a young project, so there’s lots of opportunity to get involved. I even have my eye on my second Issue already.
Tip 3: Get very familiar with version control. Almost by definition, you’re going to be jumping into the middle of a project maintained by another group of developers. You need to be able to step in and play with this team. Fork, branch, merge, rebase, good commit messages, all of that. But don’t let weakness here stop you. I’ve used git for years, but on much smaller projects than the project I contributed to. So…
Tip 4: Remember that Open Source is a community. I made it very clear in my introduction and communications with the team that this was my first Open Source Contribution. Remember both that you’re working with people and that you’re helping them with their project. This is a collaborative effort and they want you to succeed. In my pull request, I described my approach to the issue and demonstrated my willingness to accept feedback.
Tip 5: Use the systems. In order to maintain a coherent codebase with many contributors, there are going to be systems in place to ensure code quality. By using these systems (and communicating your use of them), you demonstrate your commitment to the community and code quality. For
Ray, I made sure that I wrote a unit test to cover my new feature and ran my code through their linter. In fact, I had challenges using their systems (part of the learning experience), but I communicated this with them and they helped me work through it.
Tip 6: Be willing to learn. Part of the beauty of Open Source is the ability to collaborate with developers around the globe. Be willing to exchange ideas. The
Ray Team provided me great feedback, recommending several changes to my pull request that I was happy to make. Through this experience, I learned to write better Python, learned to manage and build a large codebase, and refined my understanding of collaborative Git workflows. Overall, this was a great experience and I’m looking forward to many more. In particular, I’d like to Thank Richard Liaw who mentored me through this entire process and was incredibly responsive and helpful.