RFC-[NNNN]: [The proposal in a few words]

Replace the blue placeholders and delete the grey notes as you go. Keep the summary to one paragraph: it is the part everyone reads.

Status

[Draft / Open for comments / Final comment period / Accepted / Rejected / Postponed / Withdrawn]

Author

[Name, team]

Decider

[The person or group who makes the call]

Reviewers

[Names or teams, each with a reason: security, owners of affected systems]

Comments open

[YYYY-MM-DD]

Comments close

[YYYY-MM-DD]

Discussion

[Where comments go: channel, thread or meeting]

Related

[Design doc, decision records, earlier RFCs; supersedes or superseded by]

Statuses. A team convention, not a standard: rename them to suit your team. Draft while you write. Open for comments once it is circulated. Final comment period when the decider proposes an outcome. Then Accepted, Rejected, Postponed or Withdrawn. Implemented when the work ships; Superseded when a later RFC replaces this one.

Summary

One paragraph: what changes, for whom and from when. Someone who reads nothing else should be able to say yes or no.

We propose to [the change] for [who is affected] from [date]. [The one detail a reviewer most needs to know].

See a filled-in summary

We propose to switch off version 1 of the public API on 30 September 2027. From 1 December 2026, every v1 response will carry Deprecation and Sunset headers, and accounts still calling v1 will get a monthly email with their own call counts and a link to the migration guide.

An invented example. The date, the warning and the help for customers all fit in two sentences.

Problem

Evidence, not opinion: incidents, numbers, tickets, costs. Say what happens if nothing changes.

  • What is wrong: [the problem, with numbers and where they come from]

  • Who it affects: [teams, customers, systems]

  • If we do nothing: [what happens, and by when]

Proposal

Numbered statements reviewers can accept or object to one at a time. Delete the key-words line if you don't use them.

The key words MUST, MUST NOT, SHOULD, SHOULD NOT and MAY in this RFC are to be read as described in RFC 2119 and RFC 8174 when they appear in capitals.

  1. [Statement 1, with MUST, SHOULD or MAY]

  2. [Statement 2]

  3. [Statement 3]

Use the key words sparingly. MUST for what makes the proposal what it is, SHOULD for strong defaults with room for exceptions, MAY for options. If every line says MUST, reviewers have nothing to negotiate.

Impact

Who

What changes for them

What they must do

By when

[Team or customer group]

[The change]

[Action, or none]

[Date]

[Team or customer group]

[The change]

[Action, or none]

[Date]

Alternatives considered

Argue each option the way its supporters would. Keep the Do nothing row.

Option

What it has going for it

Why not

Do nothing

[Its real advantage]

[Reason]

[Option]

[Its real advantage]

[Reason]

[Option]

[Its real advantage]

[Reason]

Drawbacks and risks

  • Cost of this proposal: [what gets harder or more expensive]

  • Risk: [what could go wrong, and how we would notice]

Rollout

When

Step

Owner

[Date]

[Step]

[Name]

[Date]

[Step]

[Name]

Way back: [how to undo it, and the last date that is possible]

Open questions

  1. [Question] · Answered by: [name] · By: [date]

  2. [Question] · Answered by: [name] · By: [date]

Comment log

Copy every comment here from the thread or the meeting, with your response. Resolution: changed the RFC, answered, or not adopted, with the reason.

#

From

Comment

Response and resolution

1

[Name, team]

[The comment, briefly]

[Changed / answered / not adopted, and why]

2

[Name, team]

[The comment, briefly]

[Changed / answered / not adopted, and why]

3

[Name, team]

[The comment, briefly]

[Changed / answered / not adopted, and why]

See a filled-in comment

From: Support. Comment: Twelve months is too short for enterprise accounts on annual contracts.

Resolution: Changed. Switch-off moved from March to September 2027, and accounts with heavy v1 use may ask for one 90-day extension (proposal 4).

Decision

Filled in by the decider. After this, fix typos and links only; a substantial change needs a new RFC.

Outcome

[Accepted / Accepted with changes / Rejected / Postponed]

Decided by

[Name, role]

Date

[YYYY-MM-DD]

Reasons

[Why, in two or three sentences]

Follow-up work

[Task, owner, date]

Revisit if

[The evidence or feedback that would reopen the decision]

Before you open comments

  • The summary works on its own: what changes, for whom, from when

  • The problem has evidence a reviewer can check

  • Every proposal line can be accepted or rejected on its own

  • Do nothing is one of the alternatives

  • The decider, the reviewers and the closing date are filled in

  • Unused sections are deleted, not left empty