by I began my career as a trainee software developer at Codeminer 42. Throughout a three-month period, I studied web development, specifically focusing on Ruby on Rails, while receiving guidance and support from my colleagues.
After completing the trainee program, I transitioned into the “Giving Back” project. This initiative is an extension of Codeminer 42’s open source effort which aims to foster community growth by encouraging us “miners” to give back a small piece of time and effort to various open source projects.
Being part of the Giving Back project has not only helped me improve my skills but has also provided me with valuable experience in real-world projects. However, diving into the open source community can be tough, especially if it’s your first taste of real-world projects. In this post, I want to share some of my own experiences, some struggles I’ve faced, the lessons I picked up, and provide some advice for people interested in contributing to open source projects.
Selecting a Project and an Issue
Starting out in the world of open source can be quite a challenge. You’re entering a new project and community, trying to find your place while grappling with unfamiliarity. The first challenge for me was selecting a project to contribute to. The Giving Back project offered me a curated list of open source options, including RSpec, Pundit, Shoulda Matchers, and Mastodon. Initially, I set my sights on contributing to Ruby gems such as RSpec, which turned out to be a tough start.
One of the first obstacles, especially for someone relatively new like me, was the nature of these projects. Having spent most of my time as a trainee working on Ruby on Rails applications, transitioning to working with pure Ruby libraries posed a challenge. Additionally, well-established libraries like RSpec often have limited activity — few new issues and feature requests. Most of the issues I found in these projects had been open for months or even years. Were these issues forgotten or ignored? Should I spend time trying to work on them? Here the second challenge appeared: selecting an issue.
Selecting an issue is the most important step — it sets the stage for what you can contribute and where you start. For me, this step was a bit frustrating in the beginning. I would spend hours sifting through different projects and issues without feeling like I was making any progress.
That’s when I decided to change my focus to Mastodon. Mastodon is an open source, federated microblogging social media platform. It’s built using Ruby on Rails and has hundreds of thousands of active users. The project’s nature as a Rails application (as opposed to a pure Ruby library), and its bustling activity (thousands of open issues with new ones being added every day) made it feel like the right direction for me.
My First Pull Request
After browsing for a few days, I finally found an issue to tackle in the Mastodon project. It was a simple feature request. The idea was to add a new endpoint or edit an existing one in the Mastodon API. This endpoint was supposed to provide a list of languages that Mastodon supports — a static piece of information. Since the issue seemed relatively easy, I decided to dive into it and get started. It ended up being my first pull request to an open source project ever.
However, it took months before my pull request got any reviews. This experience taught me a valuable lesson: starting off with a new feature addition or editing an existing one may not be the best approach. As someone new to the project, you possibly lack knowledge of the inner workings and information about the maintainer’s immediate plans for new features. Your feature may be a good and planned one, but there’s a chance it’s not the right time for it as it may need more discussion among users, contributors, and the core team before going live. Being an “outsider”, introducing a new feature could potentially impact how your contribution is prioritized for review, possibly delaying the process.
My first contribution
Even though my first pull request initially went without reviews, I didn’t stop there. I started looking for other issues and eventually stumbled upon one that seemed fit for me. The issue in question revolved around the Mastodon CLI (Command Line Interface) tool. This tool is used by Mastodon’s instance administrators for server management and automating certain tasks. The issue described that upon creating an account through the CLI, the newly created account wouldn’t be automatically approved. As a solution, the issue suggested adding an option to the account creation command that would enable automatic approval for accounts created via the CLI.
To provide further context, Mastodon offers instance admins the option to control who can sign up for their instances. One of these sign-up options is “require approval,” which defines that a user who wants to create an account on that instance must receive approval from an admin.
The issue had had some discussions where someone had pointed out a code snippet suggesting that accounts created via the CLI were intended to be automatically approved. However, I could replicate locally that the account creation command was not presenting this behavior. As a result, the issue that at first glance seemed like a feature suggestion turned out to be a bug report.
I then worked on a pull request to implement the suggested option to the account creation command and subsequently submitted it. To my surprise, it was reviewed the next day. The Mastodon maintainer who reviewed the pull request clarified that the original intention was for the CLI to pre-approve accounts upon creation, though it had never functioned that way. Even though my pull request added an option to the command instead of enforcing pre-approval (as initially intended), my contribution was accepted and merged. This ended up being my first contribution to Mastodon and to any open source project.
However, even though it was merged, it wasn’t quite ready yet. During the trainee program, I learned about the importance of automated tests in software development. I was advised that every pull request should be accompanied by a thorough test coverage. Unfortunately, it wasn’t the case with my pull request. While working on it, I looked for tests regarding the Mastodon CLI in the codebase to gather examples of how it could be tested and I couldn’t find anything. I decided then to open the pull request without any tests and included in the description that I couldn’t find any examples of how to test it. The reviewer responded that the Mastodon CLI was one of the parts of the codebase that was severely lacking test coverage. This helped me to realize the path I could follow to further contribute to Mastodon.
I decided to give it a shot and attempt to add test coverage to the Mastodon CLI. As I worked on it, I started noticing some things that weren’t working as intended as well as some edge cases that were causing unexpected errors. This led me to uncover some bugs in the codebase. Consequently, I opened new issues reporting these bugs and also submitted pull requests to address them. These bug fixes were well-welcome and generally reviewed quickly, which gave me motivation to keep contributing to this project. Adding test coverage turned out to be a good contribution in itself, and it also helped me to find other ways to contribute.
How NOT to Get a Review
The CLI section I was working on adding test coverage consisted of a range of commands related to account management. This CLI allowed administrators to perform various actions on user accounts, including creating new ones, updating existing ones, and deleting accounts. Consequently, adding tests to each of these commands turned out to be quite an extensive endeavor. As a result, my pull request ended up huge, with lots of lines of code.
During the process of working on a pull request to add coverage to this part of the CLI, I faced some challenges that made me open the pull request as a draft in order to start a discussion and ask for help from the maintainers. One of the maintainers, who had previously reviewed my first merged contribution, answered me and helped me to advance. They were very helpful.
Once I completed the pull request, I marked it as ready for review and requested a review from that one maintainer, as they had been helping me along the way. However, this pull request never got any reviews, The pull request, in total, had over 1.7 K lines of code, which itself explained why it didn’t get any reviews.
Mastodon is a highly active project, with many new issues and pull requests emerging daily. It contains a large user base, making maintenance a formidable challenge. Consequently, the maintainers often are busy developing new features, bug fixes, and reviewing contributions. It’s reasonable to assume that they might not have the time to review a pull request with so many lines of code.
This scenario isn’t unique to Mastodon; it’s a valuable lesson for most projects, especially open source ones, often run by volunteers. Pull requests should be as concise as possible to help with the review process.
My initial pull request lingered without any reviews for over a month. During this period, I worked on different issues and also worked on some other pull requests to add test coverage to other parts of the CLI. Some of these other contributions got reviewed and merged fairly quickly. This made me realize that the main difference between the pull requests that got merged and the one that was waiting in line for a review was probably their size.
So, I decided to rework my initial pull request and split it into several ones. Each one of them focused on a single command of the CLI, instead of a single pull request for all the accounts commands. These smaller pull requests were much more concise and thus easier to review. Within a week, most of them were reviewed and merged.
This experience made it clear to me that maintainers are typically swamped with their responsibilities and may not always have the time to review every contribution, even though they welcome and value them. So, making concise pull requests should not only help with the review process but also increase the chances of your contribution receiving the attention it deserves.
Conclusions
Therefore, this whole experience taught me the fact that tackling tasks like improving test coverage, refactoring code, or addressing minor bugs often represents the most effective way to initiate your contributions to open source projects. Among these, focusing on test coverage stands out in my opinion. It not only helps you get familiar with the project and its codebase but also serves as a vital task that maintainers frequently lack the time to address. Consequently, this type of contribution typically gets accepted more easily even if you’re a newcomer to the community. Additionally, it might help you get known among other contributors, thus making your future contributions, be it a bug fix or even a new feature, more likely to get accepted.
Besides that, looking for issues tagged as “good first issues” is another good way to get started. You can find these on platforms like Good First Issue (https://goodfirstissue.dev/) and “24 PR” (https://24pullrequests.com/), which curate lists of beginner-friendly issues in several different open source projects. Regardless of the strategy you choose, I feel like starting off with small contributions is the best approach. It helps you get to know the project and the community while it helps the community get to know you. Attempting to kick off your contributions in a new project with the addition of brand new features as an “outsider” might make your contribution linger on while waiting for a review, which can be frustrating. So, starting light — like adding tests or solving technical debts — is, in my opinion, the best way to learn about the project and get recognized as a member of the community.
We want to work with you. Check out our "What We Do" section!
