Ruby Video
Ruby
Your First Open-Source Contribution
Rachael Wright-Munn
@ChaelCodes
#open-source
#ruby
#community
#mentorship
#developer-experience-dx
#pull-requests
Summarized using AI

Your First Open-Source Contribution

by Rachael Wright-Munn

The video, titled "Your First Open-Source Contribution" and presented by Rachael Wright Munn at RubyConf 2021, addresses the intimidation many feel about contributing to open-source projects. The speaker empathizes with attendees who may hesitate to jump in due to uncertainty about where to start, fear of code rejection, or concerns about the review process.

Key Points Discussed:
- Understanding the Benefits: Rachael lists several tangible benefits of contributing to open source, such as expanding skillsets, repair capabilities, and building a library of examples beyond proprietary work. She emphasizes that open source is a choice made out of joy rather than obligation.

- Finding the Right Repository: Instead of hopping between 'good first issues,' it's better to find a 'good first repo' based on factors like personal interest, closed pull requests for expectations, and familiar tech stacks to reduce the learning curve.
- Choosing Issues Wisely: Successful contributions often stem from clear, well-defined issues that are small in scope. Rachael warns against setup changes or unrequested refactors as they may be harder to get merged.
- Collaboration with Maintainers: Open-source maintainers appreciate clear contributions that demonstrate consideration for their workload and project needs. Rachael advises reading the project's contributing guidelines as they outline how to support maintainers effectively.
- Creating Effective Pull Requests (PRs): To maximize the chances of getting PRs accepted, contributors should provide clear descriptions and ensure their code adheres to testing and style guidelines.

- Building Community and Confidence: Rachael shares her journey from creating her first simple PR to gaining confidence in her skills, reinforcing that every step in the process is valuable, even if immediate results aren’t achieved. Rachael encourages attendees by stating that maintainers genuinely want contributors and that involvement enriches the open-source community.

The talk concludes with Rachael inviting questions and expressing eagerness to connect with potential contributors, emphasizing that every small contribution can lead to meaningful participation.

00:00:10.080 Hi, I am so excited to see you all here today because if you're here, that means that you want to be an open-source contributor. For me, this has been one of the greatest joys of my life. But I'm also kind of sad to see you here today because you haven't felt comfortable jumping in yet, right? I think there are a lot of big things that prevent people from feeling comfortable stepping into open source.
00:00:21.199 A lot of people are confused about where to start—there's a whole ocean of repositories and issues out there. It can be hard to know where to begin. It can also be hard to understand the differences between open-source contributions and your day job, along with the technical nuances that arise because of that. But I think the biggest factor that scares and intimidates people when it comes to open source is the review process. It is incredibly vulnerable to put your code out there publicly and have someone review it, critique it, and decide whether or not it’s acceptable.
00:00:39.920 I think a lot of this comes from the way that we view maintainers as lofty heroes of the internet. What I hope to do today is break through all of these barriers that you may be feeling and answer these questions, starting with the number one question I get every single time I work in open source on stream, which is: "Why are you doing your job for free or very cheaply?" The first thing I want to say to this is that you are not doing your work for free. Whether you want to acknowledge it or not, your work is a treadmill of issues that you need to complete to take care of your needs and your family and ensure that you have stability.
00:01:15.920 That obligation affects how you feel about it, right? Open source is an expression of joy; it is about creating things purely because you like the idea of creating them. The difference between a hobby and a job is whether or not you choose to do it. As a contributor, you have that choice. However, when I provide this answer to people, they often don’t really agree or understand it. So let's talk about the tangible benefits to you as a developer. The first two benefits are that you gain new skills and experience and learn from experts. This really comes from having the opportunity to expand beyond your organization.
00:02:11.599 Inside your organization, you have access to the projects, stacks, and architectures you’re comfortable with, and you can work with experts within your organization. But when you step into open source, you expand the possibilities. If you’ve been working with object-oriented programming, you have the opportunity to see what a large-scale functional program looks like. If you've been wanting to play with Rust, isn't it nice to build something larger than a tutorial app? You have so many opportunities to meet people you would never encounter within your organization, and that comes from stepping outside of it.
00:03:39.280 One example I often see is people on Twitter tagging the Practical Dev, requesting features. The Practical Dev team, which runs dev.to and Code Newbies, is behind an open-source platform called Forem, which is a Rails repository. You can actually go there, and they have an entire feature request process—you can be part of the project that brings your desired feature to life instead of getting caught in a cycle of begging for people to build things for you on Twitter. You can participate in the creation process, and that is incredibly empowering.
00:04:08.560 The last reason I want to highlight is having a library of examples. I once needed to provide a code sample for a job application, and as I looked through my open-source repos, I realized that everything was either locked behind copyright or just simple tutorial apps—nothing really reflected my true skills. More troubling was knowing that the best code of my career would be locked in someone else's private repository. With open source, I may not own the code I’ve written, but at least I have access to it. I can reference it when I need to build new solutions, and my history of accomplishments doesn’t end when I change careers.
00:05:04.000 That is the reason I got started with open source, and now let’s start talking about how you can get started in open source. Most people will tell you to find an issue. An issue, by the way, for those of you in Jira, isn't necessarily a problem; it could be a task or a story or another term.
00:05:16.400 They’ll tell you to look for something tagged as "good first issue." There are even sites dedicated to this, but I believe this is the wrong approach. Here’s why: setting up a development environment is hard, and learning a new codebase is hard. If you are constantly hopping from one good first issue to another, you are just repeating those two steps.
00:05:28.160 Instead, I think you should find a good first repository. What makes a good first repository will be different for each one of you, but here are the things that matter to me, and I hope they can help you create your own list. The first thing I look for is interest. I want a reason to come back—is it a tool I use? Does it have a charitable purpose? Is it built with an interesting tech stack? The next thing I do is look at closed pull requests (PRs). This lets me know how long it takes for reviews to happen and how in-depth those reviews are.
00:06:03.200 This allows me to set my own expectations for the review process and to ensure that those expectations align with what I'm comfortable with. A lot of the frustration we see in open source arises from contributors who have different expectations than the maintainers can actually fulfill. Another thing I look for is whether the repository has a Docker or Codespaces setup: anything that can reduce the setup time for the development environment is incredibly helpful.
00:06:37.760 For your first contribution, I strongly recommend using a technology stack you are familiar with—like Ruby, for example. You're going to learn about forking repositories and how to interact with maintainers and contributors, so you have a lot to pick up at once. Make your life easier by selecting a stack you already know. The last and most important feature I look for is clear issues. Out of all the repositories I’ve contributed to, the one I like most is Casa, which is an app created by Ruby for Good.
00:07:10.720 The reason this project stands out is because the issues are clear, easy to understand, and easy to work on. When I think about a good first issue, I envision one that is small in scope, well-defined, and reproducible. It’s essential for an issue to be reproducible; you want to know when you’re done. A well-defined issue is crucial—I’ve seen people pick up issues that are UI changes but without any mock-up, leading to lengthy review processes due to differences in expectations.
00:07:43.360 A good first issue should also have a small scope—like changing the color of a button. It’s perfectly fine; your heroic PR can be your second one. I want to dig deeper into this topic because finding the right first issue can set you up for success in open source.
00:08:00.400 There are a couple of common categories I see. The first one is the most difficult: setup changes. A lot of times, when contributors approach this, they think: 'Oh, I’m going to adjust the setup to make it easier for other contributors to access this project.' Audience participation: how many of you have heard of Maven?
00:08:29.120 Ah, there’s quite a few of you! Nice to see you all! In college, I hadn’t heard of Maven until a friend had this little Ruby on Rails app and he told me, "Somebody has Mavenized my repo!" I was perplexed and asked him what that meant.
00:08:40.200 Maven, by the way, is a set of build tools commonly associated with Java. As contributors, we sometimes think we want to provide a way for others to access this repo in the same way we are comfortable with, but as maintainers, we want to make sure that this repo will be accessible using Maven for the foreseeable future.
00:09:05.200 This means that it requires maintenance. Another thing people commonly forget is that build tools are some of the hardest to test in development environment setups. As a maintainer, you need to completely uninstall your environment and recreate it using the new setup. This is why, while setup changes may appear to be good first contributions, they can be some of the hardest to merge and can be challenging for maintainers.
00:09:40.320 The next category is unrequested refactors. If it’s requested, then go for it! However, I’ve seen three major issues here. The first is that maintainers may find your changes inconsistent with the rest of the codebase. Other contributors will be confused as they reference various places. Secondly, maintainers may not like your changes—code aesthetics are quite subjective, which can complicate the merging process. Finally, even if the maintainer appreciates your changes and agrees that your refactor is a good option, they might point out that you’ve changed a lot of tests and altered significant portions of the code, leading to merge conflicts for other contributors. Also, if users don’t see any new features or capabilities, they might wonder why your PR is worth merging.
00:10:34.560 The next category is challenging but rewarding. New features can be empowering and exciting; they set expectations for users regarding project maintenance and bug fixes. When creating new features, you need to provide a case for their value—not just for yourself but for others who use the project. The next category focuses on documentation contributions. Unlike the previous issues, documentation is always welcome. It benefits contributors, maintainers, and users of the project. Moreover, documentation has a low risk for maintainers, as merging it typically causes no issues in the codebase.
00:11:23.840 However, it’s important to recognize that documentation can be incredibly challenging. If you're tasked with writing documentation for a method, it’s likely that method is undocumented. Writing documentation effectively means not just listing the parameters but explaining why and how this method is used. Furthermore, if that method is undocumented, the contributor needs to deduce how to use it, which can be a daunting task.
00:12:00.160 Nonetheless, maintainers are often eager to collaborate on expanding the documentation and improving clarity. We, as an industry, need to acknowledge that this process is not easy. The last category includes easier and more welcome contributions—these could be related to existing issues. When there’s an existing issue, you have a kind of buddy system. There’s a good chance the maintainer has already seen it, and having another person to back you up on the value of the issue can make it a lot easier.
00:12:37.280 Extending current features is another category. One of the pull requests I’m most proud of is the comparison validator coming out in Rails 7. The idea is to validate that a start date is before an end date. When developing this, I was able to examine existing validators in Rails to identify patterns and reusable components, streamlining my contribution.
00:13:05.760 These extensions show the strength of open source—maintainers create a pattern, and then open source contributors can swarm in and expand it. Lastly, issues tagged as ‘good first issue’ signify that maintainers believe these issues will be small and manageable. These are often the first to go, which is why I emphasize exploring other categories as well.
00:13:35.760 There’s something critical I want to clarify: maintainers live with the code you deliver. You may drop your changes off, but when it comes to bug requests, feature expansions, and user expectations, maintainers consider the long-term future of the code you’ve provided. Understanding this perspective helps to bridge the interaction between maintainers and contributors.
00:14:13.760 But how can you understand what maintainers expect? Well, maintainers have literally written you a letter in the repository inviting you to contribute and explaining how they want you to be part of their organization. This information is included in the contributing.md file. In larger repos like Forum and Rails, it may be an entire site, while for smaller ones, it may just be a section in the README.
00:14:45.320 This document will include information on style guidelines, documentation expectations, how to request reviews, claim issues, and the necessary developer setups and testing processes they employ. One significant aspect of open source is the difference in how we handle contributions compared to traditional projects.
00:15:22.880 In your daily projects, you might reach out to someone and ask to be added to a particular project, provide your GitHub username, and they may ask you which projects you need to join. They then add you to a team, which can be cumbersome in open source since maintainers often worry they will be responsible for all the content uploaded on branches. Instead, we use forked repositories. You start with the original repo, where everything is located and where the maintainers work.
00:16:21.440 You fork that repository, creating a copy in your account where your development environment lives. This is where you'll push your changes and clone them. Finally, when ready, you point your pull request toward the original repo. If you do not point your pull request toward the original repo, as shown at the bottom of the screen, it will not be seen. It will exist only in your account and will not be reviewed.
00:17:08.240 Speaking of pull requests, let’s talk about how to enhance your chances for success. First, give it a clear description. Why do you want this? What does it change? What are some potential impacts? Include the resources you used to figure this out, making it easy to understand. Keep the pull request small and focused, and ensure that tests and linting pass.
00:17:57.280 I’ll share how I manage my repositories. I start by reviewing the list of pull requests from the bottom up, beginning with those that have passed all checks. Typically, I pay more attention to smaller pull requests first, as they are easier to review. Longer requests with more files will be prioritized later in my review queue, as they will take significantly more time.
00:18:50.000 Next, make sure it’s easy to test and reproduce. This ties into the description, and finally, provide maintainers with a quick response. They are the ones who will merge your pull request, so the shorter your feedback cycle, the faster it will get merged.
00:19:20.480 We’ve covered a lot of information, so let's take a moment to summarize. Your first step is to find a repository, then identify an issue. After that, read the contributing.md, fork the repo, and clone the forked repo locally. Set up your development environment and reproduce the issue. However, it's essential to note that most open source issues may not be valid. They’re created by volunteers, and sometimes they arise from environmental issues or have been closed in a separate pull request. So you cannot trust these issues blindly.
00:19:57.760 Once you have reproduced an issue, you can proceed with code documenting or translating. I believe in your ability to write code, document, and translate. Many times, the issue will even contain basic implementation information, so I have confidence in you to complete this step. The final step is to create a pull request and point it to the original repository.
00:20:34.160 Congratulations! You have created a pull request. That effort is worthwhile. There are many things that will happen after this stage, with plenty of back and forth. But just creating the pull request is an achievement in itself. My first pull request involved a simple image change in a Minecraft guide. It was literally a one-line change, swapping a tool rack with a cow in a jar.
00:20:56.400 It included documentation and comments, yet it went unmerged for four years. However, it taught me how to work with forked repositories. It gave me confidence to participate in open source. When I noticed that dev.to had Vimeo and YouTube but lacked Twitch embeds, I felt ready to contribute again. I created a pull request to add those embeds.
00:21:33.360 For the Jekyll project, I discovered they used liquid tags to manage embeds, which led me to learn how to create a Twitch liquid tag. This journey began with a pull request that sat unmerged for four years. Each step was worth it—even if the immediate results weren’t what I planned. Building that muscle and contributing to open source is invaluable.
00:22:08.160 There are many reasons your pull request might not be merged that have nothing to do with your code. For example, a maintainer might have 20 other pull requests to review, be on vacation, or have big work projects. Most maintainers have a full-time job alongside maintaining the project, and it’s not uncommon for that workload to go beyond 40 hours a week. If that happens, your pull request may go unmerged for a while.
00:22:44.880 Sometimes, a maintainer may also find it difficult to read or follow your PR, and they may be waiting for that reason. They might even be determining how to say no politely, even if your request is well-articulated. They may think that merging your feature request isn't in line with the project’s goals, which can be tough to handle.
00:23:08.960 On the flip side, there may be future work happening that could affect your contribution. The maintainer may decide that upcoming work means this PR would complicate long-term architectural needs. These are all valid reasons your PR might be left unmerged, even if the code itself is solid.
00:23:51.760 Now that we’ve covered contributors, let’s talk about maintainers. Here is where many anxieties arise—the fear of being reviewed publicly is common. Contributors create issues, update documentation, and create and review pull requests as they become familiar with the repository. However, maintainers manage much more—they merge pull requests, release new versions, deploy to production, and set the direction for the project.
00:24:29.520 They focus on the needs of the project, while as a contributor, you have the freedom to explore your interests. Maintainers bear the responsibility for the success of the project and its continued functionality. This leads to an important question: why would anyone want to maintain a project? Generally, there are three significant reasons.
00:25:09.520 Firstly, maintainers want the project to exist; they wish to share what they’ve built. Sometimes, they don’t even accept contributions—they simply want to showcase their work. The primary reason, however, is that they need help building and maintaining the project.
00:25:46.560 All of these reasons fundamentally boil down to the same core idea: maintainers care about their projects. When you contribute, you are sharing your time and attention with a project that they care deeply about. Many challenges can obstruct this collaboration—busy schedules, egos, and interpersonal dynamics can occasionally complicate the process. However, at the end of the day, you contribute to the project’s success, and maintainers genuinely appreciate your involvement.
00:26:19.360 I think of open source as a community garden. Maintainers are there to nurture the project, ensuring it flourishes rather than devolving into chaos. They might say: ‘Oh no, that’s not a weed; that’s actually a butterfly host plant!’ They help define the project's pathways and ensure it stays organized. Without contributors, it would simply remain an untended garden.
00:26:53.920 You are what makes an open-source project successful and remarkable. Don't be afraid—find a nice repository and build something beautiful. When you do, please tell me about it! I’m Rachael Wright Munn, and you can find me at chillcodes on various developer platforms. I stream open source on Twitch every Sunday and on two other weekdays, so feel free to join.
00:27:28.560 I’m a senior full-stack engineer at Calmly, and we are hiring. Additionally, I maintain an app called Conf Buddies built in Rails. It allows users to connect with others at conferences and coordinate event attendance. If you’re still anxious about the open-source process, I can be your first maintainer, and I promise it will be a good experience. Thank you all so much for being here today!
00:28:02.720 I’d be happy to answer any questions. Yes, you in the white cardigan and the black shirt? Yes, thank you! I’ve seen some repositories have a practice of requesting to be assigned to an issue. At what stage should I ask to be assigned? Should I scope out the problem first, or should I go ahead and ask as soon as I see something I'm interested in?
00:28:39.760 It depends on your comfort level with taking responsibility for that issue. Personally, I would recommend scoping it out first. I typically reflect on where I will make the changes and what that will look like. At that point, if I feel confident, I’ll ask to be assigned. Often, I might send a message to request assignment, and then I’ll start working on the pull request even if I haven’t been officially assigned yet.
00:29:05.440 If you realize the issue is beyond your skill level after being assigned, is there a way to step back gracefully? Absolutely! Most maintainers are incredibly understanding. Many have set up automated systems that unassign contributors so they won’t have to point out that someone hasn’t touched their issue in a month. We want to give those contributions back to the community without upsetting anyone.
00:29:45.760 In fact, maintainers often prioritize contributors' feelings regarding comfort in their projects since most communication is written. For example, there might have been a great talk on this topic where someone suggested automating emotional labor by creating a system to unassign contributors. If you find the issue is too much, it’s perfectly fine to step back—maintainers will understand.
00:30:14.560 Yes, in the weeds mask! Sorry; it’s the most identifiable thing! That was what I was unsure about. Thank you; great talk! Awesome—very helpful! My question relates to picking up an issue. In some systems, one issue can depend on others or require collaboration. How does that work in open source?
00:30:38.560 Blockages are significantly less common in open source than in our everyday workplaces because contributors often step into various parts of a workflow. It’s typical for an issue to be divided into tasks. For instance, once one task is completed and merged, that opens up the opportunity for others to pick up subsequent tasks. Does that answer your question?
00:31:18.880 Any further questions? I want to thank you all for attending. If you want to ask me further questions, you can find me on Twitch, my DMs are open on Twitter, or you can catch me in Discord. Please, don't hesitate to catch me in the halls; I love meeting new people.
00:31:34.400 When I said, ‘Tell me what you built,’ I truly mean it! Let me know when you've changed the color of a button, and I will be so excited to celebrate with you. Thank you all so much—I genuinely appreciate you!
Edit
Explore all talks recorded at RubyConf 2021
+92