Most RFC processes are theater.
The doc gets written — usually after the author has already decided what to build. It gets posted to a channel where "review" means two thumbs-up emoji and a typo correction. Three weeks later it's marked "Accepted," a status that was never in doubt, and it retires to a wiki nobody will open again. Everyone involved performs rigor; nobody receives it.
This is worth saying bluntly because the usual criticism of RFCs — "too much process" — misses what's actually wrong. The writing isn't the wasted part. The writing is the only part that works. It's everything after the writing that's fake.
The part that works
Be clear about what you're keeping before deciding what to fix:
Writing forces clarity. Drafting a proposal makes you think through the problem more rigorously than a Slack thread or a whiteboard session ever will. If you can't explain your approach in writing, you don't understand it yet.
Writing creates a decision record. Six months from now, when someone asks "why did we build it this way?", you'll have an answer instead of tribal knowledge that walked out the door.
Writing distributes context. Not everyone can attend every meeting. A well-written RFC lets the whole team understand what's being proposed and why, on their own schedule.
Writing surfaces better ideas. People who read and think before responding give better feedback than a meeting where the loudest voice wins.
All four of these benefits come from the author's side of the process. Which is exactly why RFC theater persists: the author gets real value even when the review is fake. The doc genuinely sharpened their thinking — so nobody notices that the "C" in RFC never happened.
The four tells of RFC theater
1. The template is a tax form
Fifteen mandatory sections, approval from three managers, a two-week review period — for every decision, regardless of size. When the overhead is fixed and the decisions vary, people route around the process, and the RFCs that do get written are compliance artifacts, not thinking.
2. "Review" means vibes
"LGTM." "Some concerns." A 47-comment thread where half the comments are typo fixes. None of this is review — it's engagement, performed where the author can see it. Review means someone stress-tested the load-bearing assumptions and either broke one or failed trying.
3. Nothing forces a decision
An RFC that sits "In Review" for three weeks is not being reviewed. It's being avoided. No owner, no deadline, no decision framework — the document just ages until the author quietly starts building, at which point the status gets updated to match reality.
4. Write-only storage
If accepted RFCs go somewhere nobody reads, the "decision record" benefit is theater too. The format has to meet people where they work, or the archive is a graveyard with better formatting.
Making the review as real as the writing
Keep the writing lightweight
A real RFC needs three things:
- Context — What problem are we solving and why now?
- Proposal — What specifically are you proposing?
- Questions — What do you need input on?
Add alternatives, rollout plans, or success metrics when they're relevant. Don't mandate them.
Ask questions that can fail
The single biggest upgrade. "Please review" cannot fail — any response satisfies it, including silence. Specific questions can:
## Open questions
1. Should we use PostgreSQL or DynamoDB for this use case?
Consider: query patterns, operational complexity, cost at scale.
2. Is a two-week migration window realistic given current sprint commitments?
3. Are there privacy implications we haven't considered?If nobody answers question 2, you know the review didn't happen — which is uncomfortable, and exactly the point. Theater survives on ambiguity about whether review occurred. Specific questions destroy the ambiguity.
Set a deadline
"Please review by Friday" is simple and effective. Without a deadline, reviews expand to fill available time — which is infinite.
Make the decision explicit
After the review period, the author updates the document with the decision, the feedback that shaped it, and follow-ups. This closes the loop and creates the record. An RFC without a written decision at the bottom is a draft, whatever its status field says.
Where Inkling fits
We built Inkling because we kept watching teams that believe in RFCs run the theatrical version — not from laziness, but because the tooling makes real review the harder path. The doc lives in one place, the questions in another, the responses scattered across comments and DMs.
Inkling embeds the questions directly in the RFC, next to the relevant context, and collects each reviewer's answers in one structured view. If your proposals already live in GitHub, issues can become Inkling proposals directly. It doesn't replace your process — it makes the review part of it as real as the writing part.
We're building Inkling to make technical proposals more collaborative. If your team writes RFCs (or performs them), we'd love to talk.