What Rails actually merges

It's Friday afternoon, and a query returns rows you didn't ask for. You open the Active Record source in your bundle, find the branch that builds the condition and see the fix. It's four lines.

Writing those four lines isn't the hard part. Getting them merged into a framework that countless applications depend on is a different job, with its own rules. Almost nobody explains those rules before you spend a weekend on them.

So here they are, before you spend the weekend.

The filter, stated plainly

Rails doesn't treat all contributions the same way. Three kinds of change go in through three very different doors:

That table is the whole strategy of this lesson. A documentation fix is the highest value you can produce per hour, and it's wanted. A bug fix with a failing test is the most reliable code contribution there is. A feature is a long shot, and the reason has almost nothing to do with how good your code is.

Why features get declined

Every public method Rails ships is a promise it has to keep for years. Someone will call it in production, in an application nobody on the team has ever seen, and a future refactor has to keep it working. People who didn't write it pay that cost forever.

So a maintainer isn't asking "is this correct?" or "is this well written?" The question is closer to this: does every Rails application need it, or does one? A feature that serves your architecture beautifully and serves nobody else's belongs in a gem, not in the framework. Declining it isn't a judgement on the code.

That's also why a feature idea posted as an issue with no code goes nowhere. The contributing guide asks people not to file feature requests in GitHub Issues: a new feature needs someone to write the code. If you want feedback before you build, the guide points you to the Rails core discussion board. Having that conversation first is the cheapest way to avoid writing a patch nobody wanted.

Why documentation is undersold

Developers treat documentation fixes as what you contribute when you aren't good enough for a real one. That's backwards. A wrong sentence in the API docs misleads everyone who reads it until someone fixes it. The person best placed to notice it is whoever just lost an hour to it: you, today, with the browser tab still open.

Documentation changes also skip most of the friction. There's no failing test to construct and no reproduction to reduce. And because they can't break anything, a documentation-only pull request puts [ci skip] in its title, so the full build doesn't run for it.

The part that transfers even if you never open a PR

There's a skill hiding underneath all of this. To fix something in Rails you have to read Rails, and the full source of every framework you use is already in your bundle, on this machine, right now. Learning to answer a question by opening that source, instead of searching for a blog post, is worth more over a career than most merged patches.

This course teaches contributing, and it teaches that reading habit as the thing you keep either way.

What this course covers

Lesson 2 is the executable reproduction: a single self-contained Ruby file that installs its own dependencies, boots a miniature Rails application and fails. It's the most useful skill here, because a bug report nobody can run is a bug report nobody will fix.

Lesson 3 gets a Rails checkout running on your machine. It teaches you to run one component's tests instead of all of them, and then to write the test that fails before your fix exists.

Lesson 4 is the pull request itself: the size of the diff, when a CHANGELOG entry is required and what one looks like, commit message conventions, rebasing and squashing, and what the build checks. That lesson carries the coding challenge.

Lesson 5 is what happens after you click the button, which nobody describes. It covers triage, silence, how to follow up without becoming the person everyone mutes, and why a closed pull request usually isn't about you.

Lesson 6 covers backports and release branches, and why a fix merged today may not reach your application for a year.

Lesson 7 puts you back in your own bundle, reading Rails as a primary source, and closes the loop.

Start with the reproduction. Everything else in this course depends on whether the bug can be run.