So my name is Dinah, you can find me at Dinah Shee on Twitter and GitHub. I'm a student at the University of Waterloo where I study software engineering,

but as of Tuesday, I'm 99.9% of the way through my undergraduate degree. Yay, thank you. Last year, I had this incredible opportunity to attend RailsConf 2017 in Phoenix as a scholar in the guide program, which was great. And I think that was the first time that I really realized Rails is built

by actual people. Like conceptually, I knew this. Rails didn't just appear in the world, but I don't think I really believed it until I saw a lot of the maintainers and contributors speaking. I met all of these really passionate Rails developers. And somewhere around the third day, I distinctly remember saying to myself that I was going to contribute to Rails. I didn't know how I was gonna do that.

I didn't know what I was going to work on, but I made that promise to myself. And I'm happy to report that two months later, my first pull request was merged. So this is where I admit that I was really nervous about this talk slot when I first saw the conference schedule released because it's the third day. It's right after lunch.

I was afraid that people would be tired. They would be kind of tuned out by then, but obviously that's not the case. I really tried to come to see this as a gift because reflecting upon my own journey from RailsConf last year, what I know is that you've all had two full days to marinate in the incredible conference atmosphere and all of the energy in just the environment here.

So you've heard about new releases. You've heard about the future of Rails. You've heard the ideologies of some of the people moving this project forward. And if you're in this room or you're anything like me, you wanna be a part of this. So let's get you there. My vision for this talk is not necessarily

to present completely novel ideas because I think there are a ton of great resources online about not only contributing to open source for the first time, but even contributing to Rails. So really, my goal is to set you up for success by sharing some of the resources that I found really helpful and things that I wish I had discovered earlier. So it's not gonna be a super technical talk. I'm not going to have any code examples,

but I will share a lot of links and just general best practices, I guess. So that's what a link share will look like. When I eventually release these slides, everything will actually be clickable. But if you want to see them earlier for any reason, if you Google the words that are on this slide,

it'll probably be the first hit. And the first resource I wanna share is definitely the Rails guide for contributing to Ruby on Rails. It's really well-written, it helps a lot. I'm pretty sure I had this tab open for the full two months that I worked on my first issue. So it's really great. In fact, some sections of it are so good that I'm not even gonna talk about those topics.

Things like setting up your dev environment and running tests, I think it's better if you just look at it and try things out. But before we get too deep into this talk, I wanna define what a contribution is. Actually, I wanna redefine what a contribution is. Because the Rails community is vastly brilliant.

And there are many different aspects that go into how we define this community. Not only amongst ourselves, but also to outsiders, newcomers. How do we interact and talk about newcomers? How do we interact with each other? How do we learn from and teach each other? And because there are so many different multifaceted ways that we define our community, there are so many different ways

to contribute to the community. So you can do something like keep a technical blog. These are great for sharing what you know with others, but also keeping a record for yourself. So that in a few, I don't know, weeks or months, you can look back on all that you've learned, how much you've grown. If you want a blog but you're not sure what to blog about, you can always try problems

that you've recently solved, because they're still kind of fresh in your mind. You can think about what you wanna learn in a few weeks to a few months time. And the process of writing this blog post will really help deepen your learning. Remember that you don't have to necessarily write something entirely new in the realm of knowledge.

If you can take a topic that's been discussed and blogged about over and over, but present it in a new light, or make it funny, or make it really clear and approachable for newcomers, that's still a really valuable contribution to the community. If you do wanna blog about something that's a little bit on the newer side, one of the things I would recommend is watching the newer features that come into Rails.

So for example, I think systems tests are about a year old now, and active storage was officially released just over a week ago. So there's not a ton of adoption on some of those newer features, which means there are fewer experts, and fewer experts means fewer blog posts. So if you commit to learning that feature really well, and you can share your learnings in a blog post,

or things that you found really surprising, that'll be really helpful for a large number of people. And in general, you just wanna think about this idea of sharing knowledge, sharing what you've learned with others so that they don't have to go through the same pains that you went through. You don't necessarily have to do that in a blog post form. You can answer questions on mailing lists, on Reddit,

and of course, on Stack Overflow. So there's a Rails tag on questions, and if you're feeling particularly generous one day, you can just browse those questions. If you know how to answer any of them, you can really make someone's day by unblocking them. I just picked a random question here. I haven't actually even read through all of it, but it's been viewed over 150,000 times

in the last eight years. So I don't think it's a contentious statement at all to say that this is a really valuable contribution to the community. Being at 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 really important aspect

of online communities, especially. It just makes this all feel a little bit more homey. Meeting each other, putting a face to a name, kind of talking about things that aren't necessarily technical, and understanding each other as people, that all goes into building a persona around the Rails community. And I would even go so far as to say

it builds a persona around what a Rails developer is. Because I want people to think that Rails developers are intelligent and productive. But I also want people to think that Rails developers are kind and welcoming. If you're interested in more stuff like this, there's a great talk from a few years ago called Building an OSS-Centric Company.

And Leah talks about her work on the jQuery and Ember.js teams, and how she likes to focus on these underserved areas, which are typically areas of non-technical work. Because so much has to go right in a project for it to really take off and continue to grow, and many of those things are not technical at all.

Another great resource for this is the GitHub Open Source Guides. There's a page called How to Contribute, and there's a section in that page called What It Means to Contribute. And there's just a plethora of really unique creative contribution ideas. And all of those contributions play a vital role in keeping this ecosystem going. I actually didn't find this resource

until I was preparing for this talk, but I really wish I had. I definitely recommend reading it. It really expanded my thinking of what a contribution is. So now that we've done the important work of appreciating other forms of contribution, let's talk about your first patch. Just to make sure we're on the same page, I'm going to define a patch as some change

that you wanna make to an open source project. For Rails, that's usually going to come in the form of a pull request on the GitHub repository, and it will be one of a bug fix, a feature, or a documentation change. I originally thought about sharing my first patch, so how I found it, how I worked on it, how I debugged it,

but I realized that one story isn't really enough to pull trends out of, so I ended up asking a bunch of maintainers and contributors about their first patches and how they grew in the community. And I'm gonna try to share some of the learnings that I took away from that. Pretty unanimously, people said that a good first patch is a documentation patch.

So the humble but mighty documentation patch, of course. So there's a way lower barrier to entry for these because you don't necessarily have to set up your development environment and you don't have to get the tests running. But it is a great opportunity for you to learn the flow of open source. So if you've never really worked in open source before, things like forking a repository,

pulling down from a remote, making a pull request, fetching from upstream, all of those can seem kind of confusing, and when you do it enough, it'll become second nature, but if you've never worked in an open source project before, then I really recommend starting with a smaller scope issue just to give yourself the space to learn the tooling.

And finally, I think what people forget about documentation is that as a new contributor, you are the best person to write it. I'm sure you know this from other projects. When you get really deep into a project and you're working in the nitty-gritty details, it can be kind of hard to pull yourself up out of the weeds and explain that project to someone else.

You might forget that things that you know to be true are not necessarily obvious to outsiders. You might have difficulty identifying the key points that you need to get across for someone who's consuming the project or the product, or in this case, developers using Rails, but you can't have that problem if you don't know the internals.

So bringing fresh eyes to a project can often bring a lot of clarity to documentation and messaging. If you wanna work on a documentation change, you should know that there are two main bodies of documentation in the Rails project. The one on the left is Rails Guides, which is this web view, very friendly tutorial-like tone.

It's very prosy. Wait, actually, I guess all documentation is prosy. No one's writing documentation in iambic pentameter. But if you did want to, I think that would be really cool. Probably not for the dogs, but if you write a haiku and you tweet me, that would be cool. And then the one on the right are the API docs, which are a little bit more granular.

They're at the method level. The best way to find something to work on is just to use the docs, and when you notice something wrong, whether that's a typo, a grammatical error, or something's not clear or just plain wrong, you can make a note of it and fix it later. Out of the two bodies of documentation, I definitely think the guides get a little bit more love.

So show the API docs some love. You could try just clicking around and you might find things that maybe need a little bit more work. In general, kind of similar to the idea of blog posts, you can check coverage for newer features. There's fewer people, there could be fewer people using these features, which would mean fewer people test driving the documentation.

In a similar train of thought, you can watch the pull requests. So this is almost even faster news, if that makes any sense. If you notice that someone has submitted a pull request that changes the behavior of a publicly exposed method, or they've added something but they haven't added documentation, that's a great opportunity for you to write that

in a new pull request, and you can tag the original implementer as a reviewer, because they probably know the, I guess, internals and the details of that method the best. Most of the time, you're going to be doing them a huge favor. Not everyone likes writing documentation. Some people don't have English as a first language, so they'll really appreciate the help.

If you do want to move to a code patch, this is where it gets a little bit tricky. Usually when you step into an open source project, people will tell you to fix bugs that you come across, or just look at the issues on GitHub. But that's really hard for mature projects, and it's especially hard for mature projects with lots of contributors like Rails,

because the low hanging fruit gets snatched up pretty quickly. And a lot of what's left tends to have dependencies on external factors, or is blocked on something, or is just really difficult to implement. So the first place that you should check is the good first patch label. When a maintainer comes across an issue that's a little smaller in scope,

or they think is beginner friendly, they'll try to tag it good first patch. And we actually, the maintainers tried to pull together some good first patch issues in time for RailsConf, because it's, you know, a lot of people might be really interested in contributing right after this. So if you take a look maybe tonight, you should be able to find a few newer issues.

The difficulty thing with this, or the difficult thing with this rather, is similar to lower hanging fruit, they do tend to get snatched up pretty quickly. I remember that when I was looking at the good first patch label when I first started, there were maybe one or two issues. They were kind of stale, and a lot of people had already worked on them, so I didn't really wanna fight people.

Unfortunately, if that doesn't work out for you, I don't really have a method that guarantees that you'll find an issue to work on that's interesting. But there are a lot of best practices that you can do that do help yourself and the project. So the first thing that you should definitely do is watch the repository. On the GitHub project page, there's a little button,

it says watch, click that. In your GitHub notifications, you'll kind of see all of the new things happening in Rails on a particular day. You can also try something like Code Triage, where you sign up with your GitHub account, and they have multiple open source projects, Rails is just one of them. And based on whatever preferences you set, you'll get maybe a daily email with a few pull requests

or a few issues that you could potentially work on or help review. Even if you don't wanna use any of these tools, if you just wanna log in every week and read up on the new issues, you can help a lot by verifying bugs. If you can reproduce the bug and you let people know it by adding a comment or something,

that helps, I guess that helps maintainers know that the bug is kind of not just a one-off case, and maybe it means that it needs a little bit higher priority. If you wanna go another step, you can clarify the reproduction steps, and if you wanna help even more, you can help write a bug report script if one doesn't already exist.

So on the Rails repository, and also linked on a bunch of Rails guides pages, there are these bug report templates, which are kind of like standalone scripts that you can run to reproduce the bug. So it's kind of like a distilled version, like the simplest models that you can put in to see the bug happening, and those are really helpful, obviously,

because they strip away the domain logic, and it also can be helpful if someone's running a get-by section or something like that. So you're helping yourself by making sure that this project is actually something you're interested in working on. You wanna see what the community's like. Maybe you thought contributing to Rails

would be fun and exciting, but after watching the repository for a while, you realize it's really not for you, that's fine. But you also help the project a lot by triaging issues, by reviewing pull requests, and maybe the bigger part of doing things like watching the repository and helping triage is you're building trust. Build trust and establish rapport.

So this is a really important thing. I think trust is one of the things that's hard to talk about in open source because it's really hard to quantify. I can say that I have X number of commits and Y number of open pull requests, but I can't say that people trust me with 83.7% confidence or whatever. But it's really important in open source,

especially because often we don't personally know the people that we're working with, and we might never get an opportunity to know them beyond our online interactions. So it's really important to build trust. And the way that you do that is by establishing rapport. Even if you don't commit code, but you're consistently showing up and clarifying issues,

leaving great feedback on reviews, then you start to see which names come up. And these will probably be maintainers. And you'll understand how they like to work, how they like to communicate. And in turn, others will notice your name come up a lot. They'll see that you're really interested, you're really passionate about Rails, and they'll kind of get to know how you like to work as well.

They'll see that you work well in the community, and if you're consistently leaving great feedback, that you probably have similar preferences as the team in terms of code style and organization. And that's actually really difficult to find. I actually Googled the definition of rapport to make sure I was A, spelling it right, and B, saying it right.

And the definition is really great. A close and harmonious relationship in which the people or groups concerned understand each other's feelings or ideas and communicate well. Like, I love that. I'm gonna start using this word more. You wanna get a feel for the community. You want to see how people interact with each other,

how people communicate, how others interact with you. And it's way easier for you to make a code contribution when you've established rapport, when you understand kind of what the feel of the community is. And when you show up consistently, people are way more likely to want to help you to spend a little time, spend a little bit more time on whatever it is you need from them

if you've demonstrated that commitment and if they trust you. Another way to find issues that I personally don't, I've never actually done this, so I can't really endorse it, but is to try using the Rails core mailing list. So feature requests are not usually created as issues in the Rails repository,

and some people will discuss them on the core mailing list here. But proceed with caution. You really wanna see some buy-in, ideally from a maintainer, but at least from a number of users because you wanna make sure that you're building something people actually want, not just one person wants. And even if you do see a little bit of buy-in,

you do risk building something that the core team doesn't actually envision for the future of Rails, which means even if it works, it might not get merged. So just be a little mindful of that when you're checking out features. So hopefully, from one of those tips, you found something to work on. Crossing my fingers for you.

Unfortunately, I can't guarantee it, like I said, but I think if you consistently show up and watch enough, that you will find something interesting to work on. I think this is actually the part that's almost a little easier for people because this is something we're more familiar with. So a few resources that you should check out if you're working in Rails internals for the first time.

This great talk from last year's Rails Conference, Perusing the Rails Source Code by Alex Kitchens. I actually got to see this talk live, and it was really, really helpful. It really made me think that it was actually feasible for me to contribute to Rails. In the beginning of the talk, he goes over how modules fit together, which is really helpful if you're working on an issue

but you don't even know where to start. You're not even sure which module is responsible for whatever behavior is going wrong. And then he goes through an example of digging through source code with introspection methods. So definitely check that out. There's also this great, I think this was a workshop, called Breaking Down the Barrier,

Demystifying, Contributing to Rails. This was a few years ago, but it's still very relevant, still very helpful. I think Eileen created a repository so that you can actually kind of interact with some of the things that she talks about. It's workshopping, introspection, trace points, C tags, as well as some git methods. And there's a bunch of really great resources

coming out of this year's conference as well, so I don't have photos for those, but you should definitely check them out when they are uploaded online. I've heard great things about Sean Griffin's talk on day one, Debugging with InRails. That's probably going to be really helpful. And the entire how it works track is probably going to be a safe bet,

because if you're working on one of those features that someone talks about, it helps to know how it works. It helps to know what's going on. But sometimes you need a little bit more help. Don't feel like you're working in a bubble and you can't ask for it. There are people that you can talk to, and here's where you'll find them.

The first place you should probably check is the git history. Who was the last person to touch this file or a particular line of code? That person's going to be probably the most familiar with it. You can also ask a regular contributor. How do you find a regular contributor, you ask? By watching the repository.

You can always ask a core team member. I've heard they're kind of helpful. These people might not necessarily have all the answers for you, or even if they have all the answers, they might not necessarily have the time to sit down with you and really try to debug your issues, but they'll usually be able to point you in a direction so that you can unblock yourself.

And hopefully, after some debugging, you're ready to submit a pull request. So a few things to keep in mind. Tone is really, really important. Remember that most of the people who work in open source do it in their spare time. So don't ever be entitled, don't be a jerk. I hope that goes without saying. I actually learned a lot about working

in a distributed team when I submitted my first pull request. I had never worked in a truly decentralized team before, and seeing how people communicate with one another on these pull requests really taught me that it's generally better to over-explain than to under-explain. Because if you're talking too much,

people can always just stop reading, but it's way harder to read in between the lines. And in general, it's better to be too nice. If you have a misunderstanding with someone that you sit across from at work, you can always take that discussion offline and resolve it. You can remind each other that you're working on the same team or that you have the same goals, but you don't necessarily have that luxury in open source.

So try to preempt some of those problems by being extra nice. I've seen some of the best PRs, or sorry, that didn't make sense. Some of the best PRs that I've seen are for features that I'm completely unfamiliar with in modules that I've never worked with, but reading that pull request allows me to learn

the intention, why certain decisions were made, and how whoever the implementer is came to those decisions. So remember that your pull request isn't actually just for you. It's not just for the reviewer. In an open source community, it's usually for everyone. So there's a ton of people watching the repository that would really appreciate it

if you maybe over-explained or gave a lot of context so that just by reading that pull request, they can learn what it is you're trying to do. Patience is a virtue. Again, remember that most people who work on open source do it in their spare time, so you're probably going to have slower turnaround times than you do at work. If you have a pull request or something

that's been sitting for a few weeks to a few months and no one's really been working on it, you could maybe ping someone, but be nice about it. Always watch your tone. Don't say anything like, why has this still not been reviewed or merged, whatever. And finally, if you're going to work in open source, one of the things that you have to accept is that your pull request that you worked so hard on

might never get accepted, and that's okay. Some of the reasons it might not get accepted are differences of opinion. Maybe something that you think should be in Rails other people don't necessarily think is a Rails concern, or maybe the way that you implemented something

doesn't fit with what the Rails core team or maintainers had envisioned for that feature. And you just have to be willing to accept that. But remember that it's not all wasted. You probably helped a maintainer at least discover a path that they're maybe not so interested in taking for the next feature or whatever.

And at the very least, you've grown a lot as a developer because you've learned about internals, you've learned about writing something in Rails, and that's going to help you a lot whenever it comes to you using Rails as a consumer of the API. But hopefully it does get merged, in which case you would have your first PR, you can call yourself a contributor, definitely celebrate, definitely share on Twitter

or with your friends on whatever it is that people use. That was awkward. Yeah, I definitely shared. I remember all of my friends who worked in tech were like, oh my gosh, that's so cool. And all of my friends who didn't work in tech were like, what?

So that was great. I haven't actually really shared my story of how I found my first issue because it wasn't really on one of these paths. I watched the repository, I looked at pull requests a lot. I had even gone through kind of the yak shaving of setting up my dev environment. I had tests running, but I didn't really find anything

that I felt like I could contribute to a lot or I don't know, maybe I was just really unlucky. So I ended up reaching out to Eileen and I said something like, I saw your talk at RailsConf and I was really inspired. I wanna contribute to Rails. These are the things that I've done, but I'm not really sure where to go next. I'm not really sure how to find that first issue.

So I really tried to make sure that I showed I had made an effort. At the time, she was working on some cleanup tasks around systems tests and she was really nice. She ended up sending me, I think, a few bugs and features and I ended up working on building systems tests for the Rails generate scaffold command, which you saw earlier in the presentation.

So I wanna take this time to talk about mentorship in open source communities. I was pretty surprised when I started talking to people to find that the last two additions to the core team both started in the project with some sort of mentorship. So Casper, who is the second latest addition, came into Rails through Google Summer of Code program,

which is this program that Google runs every summer to encourage students to work on open source projects. And there, there's a pretty formal structure from what I've gathered. I think there's a formal mentor title and his mentor was Rafael, who was on the core team at the time.

And Eileen, who's spoken about this in a few talks, started in Rails when she found a bug in ActiveRecord and she paired with Aaron Patterson, who was also on the core team at the time, and they worked through a few issues after that. So clearly, in the case of these two individuals, that time investment in mentorship has really paid off for the community, because both of them are on the core team now

and they mentor a lot of people and they do a lot of great work. But by no means is this strictly necessary. There are lots of maintainers who manage to make their start without a mentor, who kind of just watch the repository and are really consistent and manage to find issues on their own. But clearly, in some cases, it does help.

So I wanna go over some of the pros and cons. When you work with a mentor, especially if they're on the core team, your change is way more likely to be merged. If you're working with someone on the core team, you're probably working with a feature that the Rails team has decided they want or need in the framework, and the implementation that you choose

will probably be something that the core team is willing to go with as well. You also have a go-to person for questions, which is always nice. I've also noticed that for, especially first-time contributors who have a guide, that mentor will usually be the guide through their first PR.

So when you make your first pull request, you'll notice that a lot of strangers may start to comment, and that can be a little bit overwhelming at first. So I've noticed that sometimes the more experienced contributor will answer some of the comments and say, like, we chose this implementation because of so-and-so, and these are the other things we considered. So that's really great.

And all of these work together to ensure that your first patch experience is just really great, which means you're that much more likely to come back for a second patch, a third, to become a core team member if you so choose. But the cons are that mentorship is pretty hard, just in general, not even only in open source.

You have to find a good match between two people in terms of their working styles, their working hours maybe, their communication styles. And mentorship generally takes a long time, which means that it absolutely does not scale. I think, well, okay, I've never really been great at that game where you look at a jar of jelly beans

and you try to guess how many are in it, but I'm pretty sure there's more people in this room than there are maintainers. So even if we each got paired with a maintainer, it wouldn't really work out. Not to mention that maintainers usually have a lot of other things going on in their lives, whether that's a responsibility to the open source project or a personal life, God forbid.

So if you do decide that you wanna reach out to someone, maybe you think that it would be a really good experience for you, maybe you think that you've really tried all of the other things and it's really not working out and you're getting really frustrated, keep in mind that what you're trying to answer when you reach out to that individual is why is this worth their time? And the way that you answer that is by showing that you've really made an effort.

Do your homework. Check out all of the resources that I've linked. Look at resources that I haven't even linked. Make sure that you've actually tried all of the alternatives. And it's way easier if you approach someone with a bug that you're not sure how to fix or a feature that you're not sure how to implement. A specific direct request is way easier to answer

than something big, so they're way more likely to respond to you. And it also saves them the trouble of figuring out what you're interested in, what would be a good fit for you, your skills. And there's this great line that Katrina Owen says in a talk. Balance the size and scope of the request with the amount of trust that you've built up.

So if it's your first day in the project and you haven't really done anything, it's way more likely that if you make a large size request that it probably won't happen. But if you've consistently showed up, if people recognize your handle on GitHub, if they recognize your name,

then it's way more likely that they want to try to help you. Here's that talk. It's called Incognito Mentorship. It's really great whether or not you're interested in open source. Even if you have nothing to do with Rails, this is still a really great talk about mentorship. And another great line she says is mentorships usually happen by accident,

are informal, and are between people with an existing relationship. So maybe you build that relationship online. Or maybe if you're lucky enough to be at, I think this is the largest Rails conference in the world you can meet some of those people right now because amongst you are a bunch of contributors, a bunch of maintainers. I'm not going to point people out so that you don't just go attack them later.

But you can start building some of those relationships in person. Keep in mind, if you are reaching out to someone, it doesn't have to be a core team member. In fact, that might not actually be the best idea because core team members are some of the busiest people in a project because of all

of their other responsibilities. You can try reaching out to another maintainer or someone that's just a frequent contributor. These people will know enough to kind of help you cross that first chasm of your first pull request. Plus, if they don't usually get a ton of requests like this, they might actually be flattered rather than annoyed. Second, you don't have to call it mentorship.

I use the word mentorship because it's the word that I figured would get us all on the same page the fastest, but I don't recommend you using this word in your communication or even really thinking of it as a mentorship. Because mentorship's kind of imply, like that's a really loaded word, it implies a lot of time investment, a lot of being personally invested

in the growth of another person's career or programming or whatever it might be. But short, finite bursts of time are a way easier commitment and often that's all you really need. So I hesitate to give this piece of advice because while it worked for me really well, it doesn't scale, it's not for everyone,

and it certainly shouldn't be your default. Let's talk about what happens after the first pull request. Because I think a lot of people really like that milestone, but then aren't really sure where to go next. That's certainly what I found. I was like, okay, great, now what? Now what is you ask yourself, what do you want out of this experience? Why did you start contributing to open source?

If it's just kind of scratching an itch, if you were really curious about it and you were kind of content after that first contribution and you don't really wanna do it anymore, that's fine, power to you. If you enjoyed it and you kind of wanna take on maybe smaller issues when you do have a little bit of spare time from work or from your personal life, that's also fine.

You should really use kind of the same methods in terms of finding those things like watching the repository, code triage, check recently updated issues. All of those still work. If you really, really enjoyed it and you wanna grow and you wanna see where this can take you, then you might actually start,

you might want to start working on larger features. And in this case, I would try syncing up with a maintainer or a core team member. But definitely try to get some of those first patches first to make sure that it's something that you like doing and also to show whoever it is that you end up reaching out to that you are really committed, that you've already shown that you can do this.

To give you an idea of who you're reaching out to as well as understanding maybe what you could potentially work towards if you so please, the Rails maintainers team is kind of divided into three sub-teams. The issues team is capable of committing documentation which means that if you make a pull request that's documentation only, they can merge those,

they can accept those pull requests. As the name implies, they are also responsible for triaging issues which means closing pull requests, applying labels to issues. The committers team has kind of those capabilities and they can also commit code, which again means if you have a pull request but it's code, not just documentation,

they can accept that. The core team can do all of those things and they also have release permissions. They're responsible for determining the future of Rails and frequently I think they're also responsible for implementing some of the larger features in upcoming releases. So if you're interested in who's on these teams,

you can take a look at the community page if you just Google community Ruby on Rails, it's definitely the first hit. All of these teams are invite only via the core team which means that you don't have to do anything special. It's just a matter of working on Rails, consistently showing up, showing good judgment in your reviews, in your own code,

showing respect for other members of the community and people will notice. That was the end of that thought. Okay, so I'm gonna close with kind of the most important thing that you probably need to hear as someone who's thinking about contributing to Rails

which is that you are ready. I think there's this notion that you have to really know the ins and outs of Rails, that you have to have been working on Rails for a certain number of years to contribute to it and that's just not true. I didn't know the scaffold command existed before I added systems test to it which I'm not really sure what that says about my ability to read documentation.

If someone gave it to me in a haiku or a sonnet, maybe that would work better. And earlier this week you heard David say that no one knows every corner of Rails. So no one expects you to know every corner of Rails. You with everything that you know and everything you've yet to learn

with all of your strengths and all of your weaknesses, if this is something you wanna do, you got this. I believe in you. Thank you.