00:00:11.639
Hello! My name is Dinah, and you can find me on Twitter and GitHub at Dinah. I am a student at the University of Waterloo, studying software engineering. As of Tuesday, I am 99.9% through my undergraduate degree.
00:00:23.730
Last year, I had the incredible opportunity to attend RailsConf 2017 in Phoenix as a scholar in the guide program. This experience was great, and it was the first time I truly realized that Rails is built by actual people. Conceptually, I knew that Rails didn't just appear in the world, but I didn't fully believe it until I saw many of the maintainers and contributors speaking. I met many passionate Rails developers.
00:00:41.850
Somewhere around the third day, I distinctly remember making a promise to myself that I was going to contribute to Rails. I didn't know how I would do that or what issue I would work on, but I made that commitment. I'm happy to report that, two months later, my first pull request was merged.
00:01:05.250
Now, I have to admit, I was really nervous about this talk when I first saw the conference schedule released. It's the third day, right after lunch, and I was afraid people would be tired and tuned out, but obviously that's not the case. I really tried to see this as a gift, reflecting on my journey from RailsConf last year. I know you’ve all had two full days to soak in the incredible conference atmosphere and energy.
00:01:30.930
You've heard about new releases, the future of Rails, and the ideologies of those moving this project forward. If you're in this room or are anything like me, you want to be a part of this. So, let's get you there! My vision for this talk is not necessarily to present completely novel ideas, as there are tons of great resources online about contributing to open source for the first time, and even to Rails.
00:01:54.090
My goal is to set you up for success by sharing some of the resources I found really helpful and things I wish I had discovered earlier. This isn't going to be a super technical talk, and I won't have any code examples, but I will share a lot of links and general best practices. When I eventually release these slides, everything will be clickable. If you want to see them earlier, you can simply Google the words on this slide, and it'll probably be the first hit.
00:02:30.750
The first resource I want to share is definitely the Rails guide for contributing to Ruby on Rails. It's incredibly well-written and helpful. I'm pretty sure I had this tab open for the full two months that I worked on my first issue. In fact, some sections of it are so good that I won’t even talk about those topics, like setting up your development environment and running tests. I think it's better if you just look at it and try things out.
00:02:50.700
Before we dive deeper, I want to define what a contribution is, or rather, I want to redefine what a contribution is. The Rails community is incredibly brilliant, and there are many different aspects to how we define this community, not just among ourselves but also for newcomers and outsiders. How do we interact and talk about newcomers? How do we learn from and teach each other?
00:03:16.950
Because there are so many multifaceted ways to define our community, there are also many ways to contribute. For example, you could keep a technical blog. These are great for sharing what you know with others and also for keeping a record of your growth. If you're unsure what to blog about, consider writing about problems you've recently solved because they're still fresh in your mind.
00:03:35.160
Think about what you want to learn in a few weeks or a few months, and the process of writing this blog post can really deepen your understanding. Remember, you don't have to write something entirely new; you can take existing topics discussed frequently and present them in a new light or make them accessible to newcomers. That's still a valuable contribution to the community.
00:03:59.850
If you want to blog about something newer, I recommend keeping an eye on the latest features coming into Rails. For instance, system tests are around a year old now, and Active Storage was officially released just over a week ago. There isn’t yet a ton of adoption for some of these features, meaning there are fewer experts and thus fewer blog posts. If you can commit to learning a new feature well and share your surprising learnings, it could greatly benefit many.
00:04:23.780
In general, it's important to think about the idea of sharing knowledge and what you've learned with others so they don't have to go through the same obstacles you faced. You don’t have to do this strictly in blog post format; you can answer questions on mailing lists, Reddit, and of course, Stack Overflow.
00:04:41.160
There's a Rails tag on questions, and if you're feeling generous one day, you can browse those questions and help others. Just picking a random questions here, this one has been viewed over 150,000 times in the past eight years. I think it's safe to say this is a really valuable contribution.
00:05:02.950
Being at a Rails conference, of course, I have to talk about the importance of events. Whether you're working on an international conference or a smaller meetup in your hometown, organizing events is a crucial aspect of online communities. It makes everything feel more personal.
00:05:19.280
Meeting in person helps put a face to a name and allows discussions about non-technical topics, enhancing understanding within the community. This contributes to the overall persona around the Rails community. I want people to think that Rails developers are intelligent and productive, but I also want them to be seen as kind and welcoming.
00:05:34.500
If you're interested in more of this kind of content, I recommend a talk from a few years ago called Building an OSS Centric Company by Leia. She discusses her work with the jQuery and Ember.js teams, focusing on areas of non-technical work, as many things have to go right for a project to grow.
00:05:53.490
Another excellent resource is the GitHub Open Source Guides. There's a page called 'How to Contribute' with a section on what it means to contribute. It offers a plethora of unique and creative contribution ideas, which are vital for maintaining a healthy ecosystem. Unfortunately, I only discovered this resource while preparing for this talk, and I wish I had found it sooner. I highly recommend giving it a read.
00:06:14.700
Now that we've appreciated other forms of contribution, let's talk about your first patch. To be on the same page, I'll define a patch as any change you want to make to an open-source project. For Rails, this usually takes the form of a pull request on the GitHub repository, which could involve a bug-fix, a feature, or a documentation change.
00:06:34.620
I initially thought about sharing the story of my first patch, detailing how I found it, worked on it, and debugged it, but I realized that one story isn't enough to draw trends from. So, I asked many maintainers and contributors about their first patches and how they integrated into the community.
00:07:01.430
Unanimously, people commented that a good first patch to contribute is a documentation patch. These humble but mighty documentation changes are often a great place to start. They have a lower barrier to entry since you don’t need to set up your development environment or get tests running, which gives you a fantastic opportunity to learn the flow of open-source contributions.
00:07:26.520
If you've never worked in open source before, these processes—like forking, pulling a repository, making a pull request, and fetching from upstream—can seem confusing at first. However, once you practice, they’ll become second nature. I really recommend starting with smaller scope issues to give yourself the space to learn the tooling.
00:07:50.230
It's often forgotten that as a new contributor, you are usually the best person to write documentation. When you're deep into a project, it can be hard to explain it to someone new. You may forget that what seems obvious to you is not to someone else. Moreover, new contributors often provide fresh eyes, which can bring clarity to documentation.
00:08:15.270
There are two main bodies of documentation in the Rails project. The one on the left is Rails guides, which have a friendly, tutorial-like tone. The one on the right is the API docs, which are more granular and at the method level.
00:08:25.450
The best way to find something to work on is to use the docs. If you notice a typo, grammatical error, or something that is unclear, you can note it and fix it later. Between the two, I believe the guides receive a bit more love, so show the API docs some affection as well.
00:08:42.780
You might find things that could use a little extra care. Similarly, check the coverage for newer features, where there could be fewer people testing the documentation. You can also watch the pull requests. If you notice someone has submitted a pull request changing a publicly exposed method and they haven't added documentation, that’s a chance for you to contribute.
00:09:00.770
You can tag the original implementer as a reviewer, as they likely know the internals and details of that method best. Most of the time, you’d be doing them a huge favor. Not everyone likes writing documentation, especially if English isn't their first language, so they will appreciate the assistance.
00:09:16.850
If you’re interested in submitting a code patch, this is where things can get a bit tricky. Usually, when entering an open-source project, people recommend fixing bugs you come across or checking out the issues on GitHub. However, this can be challenging in mature projects like Rails, as low-hanging fruit tends to get snatched up quickly.
00:09:32.560
To find something manageable, check the labels, specifically 'good first patch.' When maintainers identify issues that are smaller in scope or beginner-friendly, they often tag them with this label. In fact, we tried to gather some good first patch issues in time for RailsConf since a lot of newcomers may want to contribute afterward.
00:09:49.480
The difficulty with these issues, however, is that they too can get snatched up quickly. I remember when I first looked at the good first patch label; there were only a couple of stale issues that many people had already worked on, which discouraged me.
00:10:05.850
If you have trouble finding an issue to work on, though I can’t guarantee you'll find something that interests you, many best practices can help both yourself and the project. Start by watching the repository on the Git project page. There’s a little button you can click to 'watch', which will notify you of new happenings.
00:10:22.620
You can also try tools like Code Triage, where you sign up with your GitHub account. Rails is one of the projects included, and based on your preferences, you may receive daily emails with a few pull requests or issues to consider reviewing.
00:10:37.810
Even if you don't want to use tools, simply logging in weekly to check for new issues is helpful. You can assist by verifying bugs if you can reproduce them and letting maintainers know—this helps increase awareness of the bug’s status.
00:10:52.890
If you want to take it a step further, clarify the reproduction steps. And, if there isn't already a bug report script, you can help write one. The Rails repository contains templates for bug reports, which are like standalone scripts to reproduce bugs.
00:11:05.270
These are effective because they strip away the extra context required to see the bug happening. This can also be beneficial to someone conducting a 'git bisect' to find what may have broken things.
00:11:24.080
By ensuring your interest in the project and understanding the community dynamics, you can confidently assess whether contributing to Rails is for you. If you find that contributing isn't what you envisioned, that’s perfectly okay.
00:11:39.380
However, by watching the repository and helping with triage work, you build trust and establish rapport, which is essential in open source. Trust can be a hard concept to quantify; you may say you have X number of commits, but you can’t mention the trust factor numerically.
00:12:02.170
Trust is especially critical in open source since you often don’t know the people with whom you're collaborating, and may never meet them outside of the online environment. Building rapport through constant engagement—the sharing of ideas and proactively clarifying issues—will help.
00:12:16.430
As you interact with maintainers, you'll get familiar with their preferences, understand their communication styles, and similarly, they will also become aware of your contributions. It’s also important to understand that you don't need to continually commit code to build trust. Showing reliable, consistent engagement can suffice.
00:12:36.150
Another method to find issues, not something I have experience with but worth mentioning, involves using the Rails core mailing list. Feature requests are often discussed there, but approach this option carefully. It's vital to gauge some buy-in from maintainers, as you want to ensure your idea is worth pursuing.
00:12:49.620
Even if there's some interest, be conscious that you might be building features not necessarily aligned with the core team's vision for the future of Rails.
00:13:03.710
So, hopefully, from one of these tips, you’ll find something to work on. I can’t guarantee you it’ll happen right away, but showing up consistently will increase your chances of encountering something interesting to work on.
00:13:19.030
Regarding resources, if you’re working with Rails internals for the first time, I highly recommend the talk from last year's Rails conference called 'Perusing the Rails Source Code' by Alex Kitchens. The talk made me realize that contributing to Rails was feasible, outlining how modules work together. He also covers how to dig through source code using introspection.
00:13:38.240
Another helpful resource is the workshop titled 'Breaking Down the Barrier: Demystifying Contributing to Rails.' It provides a hands-on experience for working with introspection, trace points, and Git methods. Additionally, look out for resources from this year's conference, as there have been really informative sessions.
00:14:02.320
One talk that’s received praise is Sean Griffin's on debugging within Rails. Knowing how it works can significantly help you when you're working on features aligned with these teachings.
00:14:24.890
If you find yourself in need of help, please remember it's okay to ask for it. Start by checking the Git history to see who last touched the file or line of code that you're struggling with; that person may be the most familiar with that part.
00:14:39.220
You can also ask regular contributors or core team members. They might not have every answer for you but can usually guide you in the right direction to help you unblock yourself.
00:14:53.720
Once you reach this point, you're ready to submit your pull request. A few things to keep in mind: tone is critically important.
00:15:05.920
Remember that most people contributing to open source do it in their spare time. So never feel entitled or rude.
00:15:19.730
When I submitted my first pull request, I learned a lot about how that decentralized team communicates. It’s generally better to over-explain than under-explain. Remember, over-explaining doesn’t hurt; if someone is reading too much, they can always choose to stop.
00:15:36.300
It's usually more challenging to convey the intent when you're too vague. So, provide any necessary context. Your pull request isn't just for you or the reviewer; it’s for the entire community watching, so establishing a strong context is valuable.
00:15:56.400
Patience is key. Recall that most open-source contributors work in their spare time. You might experience longer turnaround times than at work. If your pull request doesn't receive attention after weeks or even months, it’s okay to gently remind someone.
00:16:17.020
Watch your tone; avoid phrases like, 'Why hasn’t this been reviewed yet?' Always be respectful.
00:16:32.090
Understand that your hard work on a pull request may not always lead to acceptance. That's fine. There are many reasons for this, including differences in opinion or implementation not aligning with the core team's vision.
00:16:47.500
If your contribution doesn’t get accepted, don’t feel like it’s all been in vain. You’ve likely helped maintainers identify paths they might not pursue or barriers that can be crossed in the future. The experience will aid your growth as you learn about Rails's intricacies.
00:17:07.360
So, hopefully, it does get merged! You can proudly call yourself a contributor. Make sure to celebrate and share the news, whether on social media or with your friends.
00:17:18.720
I vividly remember sharing my first success—I had friends in tech who were ecstatic, while those outside of it seemed confused. So, the excitement is real!
00:17:41.380
I haven't touched on my journey in finding my first issue. It wasn't one of these straightforward paths; I was watching the repository, going through pull requests, and setting up my dev environment, but I couldn't find anything to contribute to.
00:17:58.240
Eventually, I reached out to Eileen after being inspired by her talk at RailsConf. I shared my efforts thus far and expressed uncertainty regarding where to go next. She was kind enough to connect me with bugs and features, leading me to work on systems tests for the Rails 'generate scaffold' command.
00:18:11.810
This experience brings me to the topic of mentorship in open source. I was surprised to learn many in the core team began their journey through mentorship. For example, Casper became part of Rails through Google’s Summer of Code, supported by a formal mentor.
00:18:40.080
Eileen, who’s spoken about this previously, found a bug in Active Record and worked closely with Aaron Patterson, gaining mentorship. The investment in mentorship has benefited the community significantly, as both have since taken on core team roles.
00:19:04.740
However, mentorship isn’t a strict necessity. Many maintainers find their start without any formal guidance, simply watching the repository and consistently identifying issues.
00:19:16.690
Still, mentorship holds its advantages, such as increasing the likelihood of your changes getting merged when submitting a pull request. It gives you a go-to source for questions.
00:19:36.850
Moreover, experienced contributors often guide newcomers through their initial PR by answering queries about implementation choices. This collective effort ensures that your first patch experience is smooth, making you more likely to return.
00:19:51.660
However, mentorship can be tricky. Finding the right match based on working styles and communication preferences matters. Additionally, mentorship takes a substantial time investment, which doesn’t always scale.
00:20:17.600
If you consider reaching out for mentorship, reflect on what makes it worth their time. Approach them with evidence of your efforts, showcasing the resources you’ve consulted and trying out alternative avenues.
00:20:34.680
When articulating your request, aim for specificity. A direct question about a bug or feature is easier for a busy maintainer to respond to. They will appreciate the clarity.
00:20:50.850
Katrina Owen states that it's essential to balance the scope of requests against the trust you've established in the project. If your request is large without prior involvement, it may not find favor.
00:21:08.120
However, if you’ve built rapport and established your presence, they’re more likely to assist you.
00:21:23.460
I recommend an impactful talk titled 'Incognito Mentorship,' which, while applicable in open source, is also relevant to any mentorship context.
00:21:36.740
Keep in mind that mentorship doesn’t have to be a formal title. You might build relationships without necessarily branding it as mentorship. These connections can happen organically and may lead to mutual support.
00:21:51.490
You can connect with contributors or frequent maintainers for help. They can share insights and perspectives that can greatly enhance your contributions.
00:22:05.390
Additionally, you don’t have to label your outreach as mentorship. While mentorship is a useful term, the relationship can be less formal, just a short burst of assistance. These short commitments often suffice.
00:22:18.690
Let’s now discuss what happens after you make your first pull request. Many find this milestone significant but feel uncertain about the next steps.
00:22:35.410
If you ask yourself what you want from this open source experience, define your motivation for contributing. If it’s simply to scratch an itch, and you’re satisfied with one contribution, that's perfectly fine.
00:22:51.820
However, if you enjoyed the process and seek to grow, consider working on larger features. In this case, syncing up with a maintainer or a core team member can be beneficial.
00:23:06.020
It’s advisable to secure a few successful patches first, as it would showcase your commitment to the contributing process and your ability to fulfill requirements.
00:23:24.510
The Rails maintainer team comprises three sub-teams, responsible for handling tasks like documenting and triaging issues, as well as merging code contributions. You can refer to the community page for a breakdown of these teams.
00:23:40.620
Joining these teams is an invite-only process. However, consistently demonstrating dedication, judgment, and respect within the community will catch attention.
00:23:58.520
To close, the most significant point to understand as someone thinking about contributing to Rails is that you are ready! It's a common misconception that you must be an expert in Rails or have extensive experience to contribute.
00:24:17.210
I didn’t know what the scaffold command was before I added systems tests. David emphasized during the week that no one knows every corner of Rails, so no one expects you to either.
00:24:31.020
You possess the knowledge you've gained and the experience you’re yet to acquire. If contributing to Rails is a goal for you, I believe in your ability to do it.
