AI Research Guide

Research-grade analysis on AI, marketing science, and measurement methodology.

How Do You Write a Technical RFC People Will Actually Read?

Published · Updated · 2 min read

By

Write a technical RFC as a decision document with a clear ask, only the background a new reader needs, a concrete proposal, rejected alternatives, and a rollout plan. If a section is empty, the RFC is not ready for review. Give reviewers a deadline, resolve comments in the document, and link the finished RFC from code and changelog so the decision remains findable after the thread dies.

Steps

  1. Write a five-sentence summary with the ask

    Open with the decision you need, the scope, and the deadline. If a reader cannot restate the ask, stop and rewrite.

  2. Add only the background a new reader needs

    Include facts required to evaluate the proposal. Cut history that does not change the decision.

  3. Describe the proposal with interfaces and data changes

    Show the design, APIs, migrations, and ownership. Keep the volatile details behind a clear seam.

  4. List rejected alternatives with reasons

    Document at least two alternatives and why they lost. This prevents reopening settled debates in review.

  5. Define rollout, rollback, and open questions

    Explain how you ship, how you undo, and which questions remain. Assign owners when possible.

The Point of an RFC

An RFC is a decision document. If it does not force a yes, no, or "not now," it is a blog post in the wrong folder.

The Template

Use these headings, in this order:

  1. Summary — five sentences, including the ask
  2. Background — only the facts a new reader needs
  3. Proposal — the design, with interfaces and data changes
  4. Rejected alternatives — at least two, with why they lost
  5. Rollout and rollback — how we ship, how we undo
  6. Open questions — numbered, assigned if possible

If a section is empty, the RFC is not ready for review.

How to Run the Review

Give people a deadline. Collect comments in one thread. Resolve comments in the document, not in chat folklore. The author owns the merge of feedback. Consensus is not unanimity.

After It Ships

Link the RFC from the code and from the changelog. An RFC nobody can find later did not happen.

Write the RFC you would want to read at 11pm during an incident. Short. Specific. Decisive. Keep the steps above as your checklist until the decision is recorded where the team will actually look next quarter, and treat missing sections as a hard stop rather than a soft preference you can fix after feedback arrives from reviewers who never had enough context.

Frequently Asked Questions

What is the point of a technical RFC?
An RFC is a decision document. If it does not force a yes, no, or not now, it is a blog post in the wrong folder.
How long should an RFC be?
Long enough to make the decision safe, short enough to finish in one sitting. Prefer specific interfaces over essay-length context.
Who owns merging review feedback?
The author owns merging feedback into the document. Consensus is not unanimity, and chat threads are not the source of truth.

Sources

  1. IETF RFC process overview — 2024-01-15
  2. Google Eng Practices: Code Review — 2025-06-01