rust-lang/rfcs: the repository that decides what Rust becomes

What rust-lang/rfcs is for, and who has to use it

The README states that the RFC process exists to give changes to Rust "a consistent and controlled path" so that all stakeholders can be confident about the direction of the project. That sentence is the whole product. The repository is a Markdown corpus plus a set of rules about how a proposal moves from an idea to an accepted design. The primary language listed for the repository is Markdown, which tells you what kind of work happens here: writing, arguing and revising, not compiling.

The README is explicit about who must follow the process. You need it if you intend to make "substantial" changes to Rust, Cargo, Crates.io, or the RFC process itself. It then gives examples: any semantic or syntactic change to the language that is not a bugfix, removing language features including feature-gated ones, and large additions to std. If you are a contributor who wants to add a syntax form, delete a feature or grow the standard library in a big way, this repository is the gate you have to pass.

The exclusion list matters just as much, and it is where most people misjudge the process. Rephrasing, reorganizing or refactoring code so that shape changes but meaning does not needs no RFC. Neither do additions that strictly improve objective, numerical quality criteria such as warning removal, speedup, better platform coverage, more parallelism or trapping more errors. Additions likely to be noticed only by other developers of Rust and invisible to users of Rust are also exempt, and minor additions to std are handled through an ACP instead. The README warns that a pull request implementing a new feature without going through the process may be closed with a polite request to submit an RFC first.

How the process actually works, from fork to final comment period

The mechanism is a pull request against a Markdown file, and the README lays out the sequence in order. You fork the RFC repository and copy 0000-template.md to text/0000-my-feature.md, where "my-feature" is descriptive. You do not assign an RFC number yet, because the number is going to be the pull request number and the file gets renamed accordingly if the RFC is accepted. You fill in the template, submit a pull request, and then rename the file using the issue number of that PR, updating the "RFC PR" link at the top of the file.

From there the process becomes a triage and consensus machine. Each pull request is labeled with the most relevant sub-team, which leads to it being triaged by that team in a future meeting and assigned to a member of the subteam. Discussion happens as much as possible in the pull request comment thread, and the README says offline discussion will be summarized there. The sub-team discusses the RFC, and at some point a member proposes a motion for final comment period, or FCP, along with a disposition: merge, close, or postpone.

The README is careful about what the FCP requires. It does not require consensus among all participants in the thread, which the README calls usually impossible. What it requires is that the argument supporting the disposition has already been clearly articulated, and that there is no strong consensus against that position outside the subteam. Subteam members use their best judgment in taking this step. That is the real decision rule, and it is worth reading twice: the bar is a well-argued position plus the absence of organized opposition, not universal agreement.

One operational rule stands out because it constrains your git habits. The README says you can make edits, big and small, to clarify or change the design, but to make changes as new commits to the pull request and leave a comment explaining them. It then states, in bold in the original, do not squash or rebase commits after they are visible on the pull request. Reviewers read the history of the argument, so rewriting it destroys evidence they were relying on.

Installing nothing: your first RFC pull request

There is no package to install. The repository is Markdown, and the README points to the RFC Book at rust-lang.github.io/rfcs and the Active RFC List at rfcbot.rs as the two places to read what already exists. The practical setup is a fork of the repository and a local clone, after which the first real action is copying the template.

git clone https://github.com/<your-account>/rfcs.git
cd rfcs
cp 0000-template.md text/0000-my-feature.md

The README gives exactly this copy step, with the note that you should not assign an RFC number yet. After the copy, fill in the template. The README asks for care in the details and warns that RFCs which do not present convincing motivation, demonstrate a lack of understanding of the design's impact, or are disingenuous about drawbacks or alternatives tend to be poorly received.

Once the pull request exists, the file is renamed to match the PR number and the "RFC PR" link at the top of the file is updated. The README does not give a command for the rename, but the rule is unambiguous: the 0000- prefix becomes the PR number. The repository also carries a book.toml and a generate-book.py at the top level, which is how the RFC Book is built from the text/ directory, though the README does not document running that script as part of submitting an RFC.

Before any of this, the README recommends groundwork: talk the idea over on the official Zulip server, discuss it on the developer discussion forum, and occasionally post pre-RFCs there. It also notes that you may file issues on this repository for discussion, but these are not actively looked at by the teams. That is a useful detail. An issue is not a substitute for the Zulip or forum conversation.

The failure mode is social, not technical

The README names the failure mode directly: a hastily proposed RFC can hurt its chances of acceptance. Low quality proposals, proposals for previously-rejected features, or ones that do not fit into the near-term roadmap may be quickly rejected, and the README adds that this can be demotivating for the unprepared contributor. Nothing in the repository prevents you from opening a pull request. What it cannot do is make a subteam spend meeting time on a proposal that has no prior discussion behind it.

The README offers a rule of thumb rather than a checklist: receiving encouraging feedback from long-standing project developers, and particularly members of the relevant sub-team, is a good indication that the RFC is worth pursuing. Read that as a precondition, not encouragement. If you cannot get a subteam member to engage before the pull request, the pull request is unlikely to change that.

This is also the case where the repository is the wrong tool. If your change is a bugfix, a refactor that preserves meaning, a speedup, better platform coverage, or a minor std addition, the README says it does not need an RFC, and minor std additions go through an ACP instead. Submitting one anyway adds a review burden to a team that has to triage every pull request in a meeting. The process is designed for substantial change, and using it for small change is a misuse of the same scarce attention the process depends on.

How this differs from an ordinary pull request workflow

Most open source projects route design through the same pull request system that carries code, which means a design discussion and a bugfix compete for the same review queue and the same reviewer habits. The README draws the line explicitly: many changes, including bug fixes and documentation improvements, can be implemented and reviewed via the normal GitHub pull request workflow, while substantial changes are asked to go through a design process that produces consensus among the Rust community and the sub-teams.

The concrete difference is what the artifact is. In a normal workflow the pull request contains the change. Here the pull request contains a Markdown document describing the change, and the README says the RFC is "active" once merged and may then be implemented with the goal of eventual inclusion into Rust. Design and implementation are separate events with separate review. A merged RFC is not a merged feature.

The other difference is the number. The README ties the RFC number to the pull request number, and the file is renamed accordingly if the RFC is accepted. That couples the permanent identifier of a design decision to the ephemeral identifier of the discussion that produced it. It is a small thing that makes the archive traceable: given any RFC number, you can find the thread where it was argued.

The repository also splits guidance by area. lang_changes.md, libs_changes.md and compiler_changes.md sit at the top level, and the README points to them for more detail on when an RFC is required for language, library and compiler changes respectively. If you are deciding whether your change needs an RFC at all, those three files are more specific than the main README.

Maintenance, licensing and the cost of following along

The repository is not archived and the last push was on 2026-09-10. There are no recent releases retrieved, which is consistent with a repository whose contents are Markdown documents rather than versioned software. There is nothing to upgrade, no dependency to bump and no migration to schedule. The cost of using it is the cost of the process itself: writing a document, defending it in a comment thread, and accepting that the outcome may be close or postpone rather than merge.

Licensing is stated in the repository layout rather than the README excerpt: LICENSE-APACHE and LICENSE-MIT sit at the top level alongside the Apache-2.0 licence identifier given for the repository. The README has a License section in its table of contents. If you plan to reuse RFC text or template structure outside this repository, read those two files rather than assuming a single licence applies. This is a description of what is present, not legal advice.

There is one maintenance detail worth noting for anyone who contributes: the repository carries a triagebot.toml and a .github/ directory at the top level. Those are the automation around labels and PR handling that the README alludes to when it says each pull request will be labeled with the most relevant sub-team. The README does not document the bot's configuration, so if you want to know how labeling actually resolves, that file is where to look.

Editorial conclusion

Adopt this process only if you intend to change Rust, Cargo, Crates.io or the RFC process itself, and only after reading lang_changes.md, libs_changes.md or compiler_changes.md for the area you are touching. If your change is a bugfix, a refactor, a numerical improvement or a minor std addition, the README says it does not need an RFC, and an ACP covers the std case. Before opening a pull request, verify three things: that the idea has been discussed on the official Zulip server or the developer discussion forum, that the file you copied is still named 0000-template.md at the repository root, and that you can commit to not squashing or rebasing once your commits are visible on the pull request.

Frequently asked questions

Official sources

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