Stackbook Logo
decision-makingestablished · medium operational burden

RFC Process

Also known as: design-doc-review, request-for-comments

Intent

Make significant technical decisions through written proposals reviewed asynchronously by affected stakeholders.

Problem

Large changes are decided in meetings or in code, excluding people who bear the consequences. Context is lost, and the same debates recur. Late objections cause expensive rework.

Forces

  • •Cross-team changes need broad input
  • •Review time competes with delivery pace
  • •Decisions need durable rationale
  • •Too much process stalls small changes

Solution

Overview

An RFC is a written proposal that invites comment before a significant change is built. It trades a little speed up front for fewer surprises later. Rust, Python (PEPs), and many companies use variants.

Good RFCs are short, typically two to five pages. Their value is the alternatives section, which forces authors to show that other options were considered and why they lost. Reviewers should comment on risks and missing cases, not preferences.

How it works

The lifecycle is explicit and time-boxed.

Draft --> In Review (7-14 days) --> Decision
                                  |--> Accepted --> ADR + tickets
                                  |--> Rejected (kept, with reasons)
                                  `--> Withdrawn
Template: Context | Proposal | Alternatives | Risks | Rollout | Open questions

Choose where RFCs live, typically a repository with pull requests so comments are threaded and history is kept. Tag affected teams automatically with code owners, and close the loop by marking status and linking to the delivered change so future readers see the outcome.

Pitfalls

  • Writing the RFC after coding, which makes review theatre
  • Leaving the decider unnamed, so there is no way to close
  • Requiring RFCs for everything, which teaches people to avoid them
  • Not recording rejected options, so debates repeat

Key takeaways

  • Define a threshold for when an RFC is required
  • Time-box review and name a decider
  • Always list alternatives considered
  • Link accepted RFCs to ADRs and delivery work

✓ When to Use

  • •Changes affecting multiple teams or public APIs
  • •Choices that are expensive to reverse
  • •Introducing new infrastructure or shared libraries

✗ When Not to Use

  • •Small, reversible, single-team changes
  • •Urgent incident mitigation
  • •Matters of personal style already covered by linters

Pros

  • +Surfaces objections before implementation
  • +Creates searchable decision history
  • +Includes remote and junior voices

Cons

  • −Slows decisions if windows are not enforced
  • −Can devolve into bikeshedding
  • −Authors may write to win rather than to learn

Cost Profile

Infrastructure

None - repository or wiki

Operational

Medium - reviewer time

Cognitive

Low

Failure Modes

  • RFCs written after the decision is already implemented

  • No decider, so threads never close

  • Threshold too low, flooding reviewers with trivia

Real-World Examples

Alternatives

    Related Patterns

    • architecture-decision-records
    • architecture-reviews

    Competency Domains

    economics evolutionrequirements constraints