Every section you add to your RFC template subtracts one person willing to write an RFC.
That's the trade nobody prices in. Teams design their template for the biggest, scariest decision they can imagine — fifteen sections, security review, capacity planning, "how we teach this" — and then wonder why engineers make medium-sized decisions in Slack DMs. The template turned a writing task into a tax form, and people respond to tax forms by not filing.
The template's job is not to be thorough. Its job is to be filled out. A three-section RFC that gets written beats a fifteen-section RFC that doesn't, every single time.
Here are three templates sized to the decisions teams actually make. Pick the smallest one that fits, copy it, and spend your saved energy on the part that matters — getting people to respond.
Template 1: Lightweight RFC
This is for decisions that need a paper trail but don't need a novel. Use it for most things: a new API endpoint, a library swap, a change to your deploy process.
# RFC: [Title]
**Author:** [Name]
**Date:** [Date]
**Status:** Draft | In Review | Accepted | Rejected
## Context
What's the problem? Why does it matter now? Keep this to 2-3 paragraphs.
## Proposal
What are you proposing? Be specific enough that someone could
implement it from this description.
## Alternatives considered
What else did you look at? Why did you rule it out?
One paragraph per alternative is fine.
## Open questions
1. [Specific question for reviewers]
2. [Another specific question]
3. [One more]
## Decision
[Filled in after review period ends]The open questions section is the most important part. "Please review" gets you silence. "Should we use Postgres or DynamoDB given our query patterns?" gets you an answer. (How to write questions reviewers can't brush off is worth reading before your next RFC.)
Template 2: Standard RFC
For cross-team decisions, migrations, or anything that affects more than your immediate team. This adds sections for rollout planning and risk — and only those, because they're the two things cross-team reviewers actually ask about.
# RFC: [Title]
**Author:** [Name]
**Date:** [Date]
**Status:** Draft | In Review | Accepted | Rejected
**Reviewers:** [List specific people]
**Review deadline:** [Date]
## Context
What problem are we solving? Include enough background that someone
outside your team can follow along. Link to relevant issues,
metrics, or incidents.
## Proposal
### Overview
One-paragraph summary of the approach.
### Detailed design
The specifics. Diagrams, API schemas, data models — whatever
makes the proposal concrete. This section should answer "how"
in enough detail to evaluate feasibility.
### Rollout plan
How do we get from here to there? Phases, feature flags,
migration steps.
## Alternatives considered
| Approach | Pros | Cons | Why not |
|----------|------|------|---------|
| Option A | ... | ... | ... |
| Option B | ... | ... | ... |
## Risks
What could go wrong? What's the blast radius if it does?
## Open questions
1. [Question] — Context: [why this matters]
2. [Question] — Context: [why this matters]
3. [Question] — Context: [why this matters]
## Decision
**Outcome:** [Accepted / Rejected / Modified]
**Date:** [Date]
**Key feedback:** [Summary of what influenced the decision]
**Follow-ups:** [Any action items]The reviewers and deadline fields aren't optional. An RFC without a deadline is a document that never gets decided.
Template 3: Mini RFC
For small decisions that still benefit from a written record. A Slack thread would work, but you want something you can find six months from now. Think: renaming a service, choosing between two libraries, changing a default config value.
# RFC: [Title]
**Author:** [Name] | **Date:** [Date] | **Status:** Draft
## What and why
[2-3 sentences. What are you changing and why?]
## The options
**Option A:** [Description]
**Option B:** [Description]
**Recommendation:** [Which one and why]
## Input needed
- [One specific question]
## Decision
[Filled in after review]This takes five minutes to write. It's not overhead — it's a decision log that future-you will thank present-you for. (If what you're recording is an architecture decision specifically, an ADR is the same idea with a longer shelf life.)
The template is the easy 20%
Copy any of the above and you have a working RFC format by tomorrow. But the format was never the reason your last RFC died. It died after you shared it:
The ask was too vague. "Please review this RFC" means "please add it to the pile of things you'll get to eventually." Specific questions get specific answers.
There was no deadline. Without one, reviews expand to fill available time — which is infinite.
Feedback scattered. Comments in Google Docs, replies in Slack, a thumbs-up emoji in the PR. Good luck synthesizing that into a decision.
Nobody answered the actual questions. Your three sharp open questions sat at the bottom of the document, below the fold of everyone's attention. Reviewers skimmed, left a "looks reasonable," and never reached the part where you needed them. (This is how most RFC processes become theater.)
The questions get the decision made
Templates structure your thinking. They don't structure the response — and the response is where RFCs go to die.
This is why we built Inkling. It lets you embed your open questions directly into the proposal — inline, next to the relevant context, where reviewers can't scroll past them. Paste a GitHub issue URL, add questions, share a link; reviewers answer in the flow of reading, no account or repo access needed, and responses come back structured and attributed.
The template gets the proposal written. The questions get the decision made.