Leader: RFC process
This course covers the RFC process for technical decisions that one person cannot make alone. It follows one example from a repository: Admin::StatsQuery, a 390-line query that returns eight chart JSON fields against a documented rule forbidding presentation logic in queries. The lessons cover when an RFC is needed, the sections of the document, and a complete written proposal. They then cover running a written review, what consensus means and where it stops, turning the decision into an ADR, and a two-week walkthrough of the whole sequence.
What you'll learn
- ✓The four triggers that call for an RFC
- ✓The eight sections of an RFC and why three differ from an ADR
- ✓Running a written, asynchronous review with required and optional reviewers
- ✓Telling blocking objections apart from preferences
- ✓Announcing a decision and turning the RFC into an ADR
- ✓Archiving decided and rejected RFCs
When you need an RFC
An ADR records a decision that was made. An RFC is how a decision gets made when it cannot be made in one person's head.
Read the full lesson free →Curriculum
7 lessonsWhen you need an RFC
Four triggers for an RFC, and a 390-line stats query that breaks a documented rule for a caching reason.
The shape of an RFC
The eight sections of an RFC, its length, where it lives, and why the decider is named up front.
Writing the proposal
A complete RFC for moving chart formatting out of Admin::StatsQuery, with unmeasured costs and a possibly better alternative.
Running the review
Running a written review with required and optional reviewers, hard moments, the decision announcement, and disagree and commit.
Consensus and its limits
Consensus as everyone heard and one person deciding, design by committee, blocking objections and endless threads.
After the decision
Turning the RFC into an ADR, archiving it, adding one rules line, and keeping rejected RFCs.
Putting it together: two weeks
A two-week walkthrough of RFC 0004, where one measurement changed the outcome without any meeting.