Rust RFCs and the file naming trick that gives every proposal a number

A document repository, not a place where changes happen

The distinction matters before anything else. Bug fixes and documentation improvements go through the ordinary GitHub pull request workflow and never appear here. This repository holds the written proposals for changes that are called substantial, so that there is a consistent and controlled path for them and stakeholders can be confident about the direction of the project. The mechanism is merging, not approving in the abstract sense: to get a major feature added, the RFC is merged into this repository as a markdown file, and at that point it becomes active and may be implemented with the goal of eventual inclusion into Rust. Two public entry points sit above the repository: the RFC Book at rust-lang.github.io/rfcs/, which renders the merged documents, and the Active RFC List at rfcbot.rs. That split decides where you read and where you write, since the book is for reading and the repository is for proposals. The repository has no releases; its licence is listed as Apache-2.0, and the root carries both LICENSE-APACHE and LICENSE-MIT.

Substantial narrows down to three kinds of change

The definition is described as evolving with community norms and varying by which part of the ecosystem you are changing, and the scope covers Rust, Cargo, Crates.io and the RFC process itself. Underneath that soft framing sit three concrete triggers. The first is any semantic or syntactic change to the language that is not a bugfix. The second is removing language features, including ones that are behind a feature gate. The third is large additions to std. Note what the first trigger excludes: a bugfix is a change of meaning, so it stays on the pull request path.

Four categories that skip the process, and one that only needs an ACP

The exclusions are as precise as the triggers. Rephrasing, reorganizing and refactoring are exempt under a single rule: changing shape does not change meaning. So are additions that strictly improve objective, numerical quality criteria, with the given examples being warning removal, speedup, better platform coverage, more parallelism and trapping more errors. A third exemption covers additions that other developers of Rust would notice but users of Rust would not, which is a line drawn between audiences rather than between sizes. Minor additions to std do need a process, but a lighter one: an ACP, with the lifecycle explained in the standard library developer guide. The consequence of guessing wrong is soft but real. A pull request implementing a new feature without an RFC may be closed with a polite request to submit an RFC first.

The 0000 placeholder is replaced by the pull request number

Start from a fork and a copy of the template, with a descriptive name rather than a number:

git clone https://github.com/rust-lang/rfcs
cp 0000-template.md text/0000-my-feature.md

The 0000 is deliberate. No RFC number is assigned up front, because the number will be the pull request number and the file is renamed once the pull request exists. After opening it, update the 0000 prefix to the issue number and fix the RFC PR link at the top of the file so the proposal and its discussion stay tied together. Before any of that, read the guidelines for the area you are touching: language changes, library changes and compiler changes each have their own file, lang_changes.md, libs_changes.md and compiler_changes.md, and each defines when an RFC is required there. Teams differ enough that the generic rule can be wrong on its own.

Consensus is built in the comment thread, so never rewrite history

Once the pull request is open, discussion happens there as far as possible, and anything discussed offline gets summarized onto the same thread, which keeps one record. Each pull request is labelled with the most relevant sub-team, which triages it in a future meeting and assigns a member; that assignee is the person to ask for help finding the stakeholders you missed. There is a hard constraint on how you edit, and it is unusual enough to be worth quoting: make changes as new commits to the pull request, leave a comment explaining what changed, and specifically do not squash or rebase commits after they are visible on the pull request. The reason is the same record. Rebasing erases the sequence reviewers argued through, which is most of the evidence that a design was actually tested.

An FCP asks for a decision, not a crowd

Eventually a sub-team member proposes a motion for final comment period, alongside a disposition of merge, close or postpone. The bar for that motion is lower than the language of consensus suggests, and the text is explicit about why. Reaching agreement among everyone in an RFC thread is described as usually impossible, so it is not required. What is required is that the argument for the disposition has already been clearly articulated, and that there is not a strong consensus against that position outside the sub-team. Sub-team members use their own judgment in taking the step, so the final comment period begins with a stated outcome instead of an open question. Postponement is a real outcome rather than a polite delay, and so is closure, which is why the pre-submission advice in this same document spends so much effort on avoiding a rushed first draft.

Preparation happens on Zulip, because issues here go unread

The bluntest line in the document is also the most useful one: you may file issues in this repository for discussion, but they are not actively looked at by the teams. So the preparation route runs elsewhere. The named options are talking the idea over on the official Zulip server, discussing it on the developer discussion forum, and occasionally posting a pre-RFC on that forum. The stated reason is that a hastily proposed RFC hurts its own chances. Low quality proposals, proposals for features already rejected, and proposals that do not fit the near-term roadmap may be turned away quickly, which the document calls demotivating for the unprepared contributor. Three rejection categories are named there, and one of them is about timing rather than quality: a proposal can be argued well and still not fit the near-term roadmap. The rule of thumb offered instead is social rather than procedural: encouraging feedback from long-standing project developers, and from members of the relevant sub-team in particular, is a sign the proposal is worth pursuing.

What the process text does not tell you

Four absences are worth knowing before you plan around this repository. The trigger for a substantial change is deliberately left to community norms, which means two honest readers can classify the same pull request differently and both be quoting this document. And the quality bar is described only in prose, in terms of convincing motivation, grasp of the design's impact, and being candid about drawbacks and alternatives. Nothing in the repository scores a draft against it.

Editorial conclusion

Read rust-lang/rfcs when you want to know why a Rust design decision looks the way it does, or when you are about to write a proposal and need the real bar. Ignore it if your change is a refactor, a speedup or a warning cleanup, because those paths deliberately never touch the process. Before opening a pull request, take the idea to Zulip or the developer forum first, because issues opened here are not actively looked at by the teams.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. rust-lang/rfcs on GitHub