Plenty of teams want an RFC process but don't know what one looks like in practice. The good news: several major open-source projects run theirs in public, with years of history you can study.
We studied five. Here they are, ranked from most to least worth copying — with the specific piece to steal from each, and the failure mode every single one of them shares.
The ranking criterion is simple: does the process reliably convert proposals into decisions? Not "is the discussion rich" or "is the governance fair" — does the thing decide.
1. Go — the only one with a forcing function
Go uses a proposal process rather than calling them RFCs, but the function is the same.
How it works: Proposals start as GitHub issues in the main Go repo, not as PRs to a separate repo. A design doc accompanies larger proposals. A proposal review committee meets weekly and triages every active proposal through a defined decision process.
Why it wins: The weekly committee meeting is a forcing function, and it's the only one on this list. Proposals don't languish — they get looked at every week until they reach a terminal state. Every other process here relies on a thread eventually exhausting itself; Go schedules the deciding. Using issues in the main repo (instead of a separate RFC repo) also means proposals are discoverable right next to the bugs and features they relate to.
The tradeoff: The committee model concentrates decision-making. Community feedback exists in issue comments, but a committee you're not on makes the call. At Go's scale this is probably necessary — and for a company team, "a named group meets weekly and decides" is exactly the property you want.
Steal this: the standing weekly triage. It's the highest-leverage piece of process design in this post.
2. Rust — the gold standard for rigor, at a price
Rust's RFC process is the one most other projects copied. It lives in rust-lang/rfcs and has been running since 2014.
How it works: Fork the repo, copy the template into text/0000-my-feature.md, open a PR. The community discusses in PR comments. A relevant team (lang, libs, compiler) eventually moves to accept, reject, or postpone. Accepted RFCs get merged and assigned a tracking issue.
Why it ranks high: Democratic, transparent, and the accepted RFCs form the best public record of "why the language is like this" in the industry. The template's "guide-level explanation" section is quietly brilliant — it forces the author to explain the feature as if writing documentation, which catches usability problems before a line of code exists.
The price: Active RFCs get hundreds of comments. RFC 2005 (match ergonomics) passed 300. Finding the core arguments in a thread that long is archaeology. Rust's own fix is telling: they invented the Final Comment Period — a formal mechanism to force threads to end — because without it, controversial RFCs lived in limbo for months. When a process needs an institutional escape hatch from its own comment section, the comment section is the problem.
Steal this: the guide-level explanation section, and FCP if you have no better way to force endings.
3. npm — the best lifecycle tracking
npm adopted an RFC process modeled on Rust's, in npm/rfcs.
How it works: Fork, write, PR — with a lighter template: summary, motivation, detailed explanation, rationale and alternatives, prior art, unresolved questions. Accepted RFCs go into an accepted/ directory; implemented ones move to implemented/.
Why it ranks here: The accepted/ → implemented/ split is a genuinely good idea that almost nobody else has. Most processes can't tell you whether an accepted RFC ever shipped. npm's directory structure makes the answer visible at a glance.
The weakness: Same PR-comment model, same buried feedback — and it's often hard to tell what the maintainers think versus what a passing community member suggested. The signal-to-noise ratio of the threads is low, and nothing in the process concentrates it.
Steal this: the implemented/ directory.
4. Ember — one great template idea, opaque decisions
Ember's RFC process was also explicitly inspired by Rust's.
How it works: Fork, write, PR. The template adds a section the others lack: "How We Teach This." Core team members shepherd RFCs through.
Why that section matters: It forces the author to think about documentation, migration guides, and developer experience before the feature is built — catching the "great design that's impossible to explain" failure that purely technical templates miss. It's Ember's lasting contribution to RFC design, and React later borrowed it.
The weakness: Decisions often happen in a core team meeting, off-thread. The RFC thread tells you what the community said; the actual decision and its reasoning sometimes appear as a brief comment after the fact. The record — the whole point of writing things down — has a hole where the decision should be.
Steal this: "How We Teach This." Skip the off-thread deciding.
5. React — proof that a process you don't use isn't a process
React has an RFC repo, and when it's used, the quality is high — the Hooks RFC discussion surfaced real concerns about debugging and the rules of hooks that shaped the final design.
Why it ranks last: It's barely a process. Some major React changes go through RFCs; others arrive as blog posts or conference talks. Some RFCs sit open for years without a decision. The inconsistency is worse than either extreme would be — the community can't tell when it will have input and when it won't, which converts every skipped RFC into a small betrayal of the process's promise.
The lesson: an RFC process is a commitment device. Applied selectively, it stops being one.
What all five share
Every process on this list does two things well:
- They force proposals into writing. Even a mediocre template makes the author clarify their thinking. This alone is worth having a process.
- They create a public record. You can go back and read why any decision was made — invaluable for long-lived projects with rotating contributors.
And every one of them — including the winner — has the same failure mode:
Feedback collection is a mess. All five settled on the same format: a document with a flat comment thread underneath. Good feedback mixed with bikeshedding. The author's actual questions buried under general commentary. Quiet experts staying quiet while the thread rewards stamina over insight. Rust needed FCP, Go needed a committee, and npm and Ember just live with it — every mitigation on this list is a workaround for the thread, and none of them fix it.
What's missing everywhere is structure between the proposal and the responses: a way to say "here are the three things I need input on" and get back "here's what each reviewer said about each one" — without reconstructing it from 200 comments. The templates work. The processes mostly work. The feedback layer is the unsolved part.
If you're setting up a process for your own team: copy Go's weekly triage, Rust's guide-level section, npm's implemented/ directory, Ember's teaching section — and then spend your remaining effort on the part none of them cracked: asking reviewers questions they can actually answer, in a format that keeps the answers organized. That's the difference between a real review and a performed one.