After RailsConf this year, I joined the Rails Issue Team. This means that I help triage issues that people have filed, try to reproduce errors, and point core team members at ones that are most important. Since doing that, a few people have asked me how to get started, so I decided to draw up my thoughts here.
Note that there is also an official Rails Guide on contribution too.
First up is the Rails Core team: http://rubyonrails.org/core/ Core team members essentially have the authority to merge code into the main Rails codebase. Someone from core reviews every patch that goes into Rails.
Issues team: This group of people has the authority to tag, close, and edit tickets, but can’t actually merge code.
Documentation team: A few awesome people contribute by writing documentation rather than just code. Docs are super important, so all these people are also awesome.
Everyone else!: Rails is open source after all, and 1224 people have contributed at least one patch.
You can find everyone’s commits and count here: http://contributors.rubyonrails.org/
Nobody is paid to just work on Rails itself. Everyone is a volunteer. Rails runs on a ‘scratch your own itch’ policy. This has two big effects:
File a ticket on the Rails issue tracker and give us as much information as possible.
Note that only 3.2 is getting bug fixes. 3.1 and earlier are security fix only.
Good: Clear bug report, listed versions of Rails and/or Ruby and backtrace if applicable
Better: Steps to reproduce, maybe with a sample app.
Best: All of the above with a patch that fixes the problem.
Don’t submit something to the tracker. Instead, check out this page which outlines the security policy. Basically, send an email to email@example.com.
Please don’t file an Issue; it’s a bad medium for discussing these kinds of things. It also makes it harder to keep track of what’s a bug and what’s a wish for future changes. Please post to the rails-core mailing list instead. Your idea is much more likely to be seen and discussed there.
You may get no response from the list. People tend to say nothing if they’re not interested. It happens.
Same as a feature request, please ping the rails-core mailing list.
Submit a pull request with your patch. Someone from core will review it, and may ask you to modify what you’ve done. Eventually it will either get merged into Rails or rejected.
Don’t sumbit them as issues to the main Rails repo, instead, check out docrails.
We try to tag each issue with the part of Rails it affects. If you don’t know where to get started, pick your favorite part of Rails and sort the issues by that part. For example here are all the issues relating to the asset pipeline.
Try to reproduce the bug locally, write a test that fails, write a patch, boom!
Check the Rails Guide here.