Repository files navigation

The "RFC" (request for comments) process is intended to provide a consistentand controlled path for changes to Rust (such as new features) so that allstakeholders can be confident about the direction of the project.

Many changes, including bug fixes and documentation improvements can beimplemented and reviewed via the normal GitHub pull request workflow.

Some changes though are "substantial", and we ask that these be put through abit of a design process and produce a consensus among the Rust community andthesub-teams.

• Opening
• Table of Contents
• When you need to follow this process
• Sub-team specific guidelines
• Before creating an RFC
• What the process is
• The RFC life-cycle
• Reviewing RFCs
• Implementing an RFC
• RFC Postponement
• Help this is all too informal!
• License
• Contributions

You need to follow this process if you intend to make "substantial" changes toRust, Cargo, Crates.io, or the RFC process itself. What constitutes a"substantial" change is evolving based on community norms and varies dependingon what part of the ecosystem you are proposing to change, but may include thefollowing.

• Any semantic or syntactic change to the language that is not a bugfix.
• Removing language features, including those that are feature-gated.
• Changes to the interface between the compiler and libraries, including langitems and intrinsics.
• Additions tostd.

Some changes do not require an RFC:

• Rephrasing, reorganizing, refactoring, or otherwise "changing shape doesnot change meaning".
• Additions that strictly improve objective, numerical quality criteria(warning removal, speedup, better platform coverage, more parallelism, trapmore errors, etc.)
• Additions only likely to benoticed by other developers-of-rust,invisible to users-of-rust.

If you submit a pull request to implement a new feature without going throughthe RFC process, it may be closed with a polite request to submit an RFC first.

For more details on when an RFC is required for the following areas, please seethe Rust community'ssub-team specific guidelines for:

• language changes,
• library changes,
• compiler changes.

A hastily-proposed RFC can hurt its chances of acceptance. Low qualityproposals, proposals for previously-rejected features, or those that don't fitinto the near-term roadmap, may be quickly rejected, which can be demotivatingfor the unprepared contributor. Laying some groundwork ahead of the RFC canmake the process smoother.

Although there is no single way to prepare for submitting an RFC, it isgenerally a good idea to pursue feedback from other project developersbeforehand, to ascertain that the RFC may be desirable; having a consistentimpact on the project requires concerted effort toward consensus-building.

The most common preparations for writing and submitting an RFC include talkingthe idea over on ourofficial Zulip server, discussing the topic on ourdeveloper discussion forum, and occasionally posting "pre-RFCs" on thedeveloper forum. You may file issues on this repo for discussion, but these arenot actively looked at by the teams.

As a rule of thumb, receiving encouraging feedback from long-standing projectdevelopers, and particularly members of the relevantsub-team is a goodindication that the RFC is worth pursuing.

In short, to get a major feature added to Rust, one must first get the RFCmerged into the RFC repository as a markdown file. At that point the RFC is"active" and may be implemented with the goal of eventual inclusion into Rust.

• Fork the RFC repoRFC repository
• Copy0000-template.md totext/0000-my-feature.md (where "my-feature" isdescriptive). Don't assign an RFC number yet; This is going to be the PRnumber and we'll rename the file accordingly if the RFC is accepted.
• Fill in the RFC. Put care into the details: RFCs that do not presentconvincing motivation, demonstrate lack of understanding of the design'simpact, or are disingenuous about the drawbacks or alternatives tend tobe poorly-received.
• Submit a pull request. As a pull request the RFC will receive designfeedback from the larger community, and the author should be prepared torevise it in response.
• Now that your RFC has an open pull request, use the issue number of the PRto rename the file: update your0000- prefix to that number. Alsoupdate the "RFC PR" link at the top of the file.
• Each pull request will be labeled with the most relevantsub-team, whichwill lead to its being triaged by that team in a future meeting and assignedto a member of the subteam.
• Build consensus and integrate feedback. RFCs that have broad support aremuch more likely to make progress than those that don't receive anycomments. Feel free to reach out to the RFC assignee in particular to gethelp identifying stakeholders and obstacles.
• The sub-team will discuss the RFC pull request, as much as possible in thecomment thread of the pull request itself. Offline discussion will besummarized on the pull request comment thread.
• RFCs rarely go through this process unchanged, especially as alternativesand drawbacks are shown. You can make edits, big and small, to the RFC toclarify or change the design, but make changes as new commits to the pullrequest, and leave a comment on the pull request explaining your changes.Specifically, do not squash or rebase commits after they are visible on thepull request.
• At some point, a member of the subteam will propose a "motion for finalcomment period" (FCP), along with adisposition for the RFC (merge, close,or postpone).
  • This step is taken when enough of the tradeoffs have been discussed thatthe subteam is in a position to make a decision. That does not requireconsensus amongst all participants in the RFC thread (which is usuallyimpossible). However, the argument supporting the disposition on the RFCneeds to have already been clearly articulated, and there should not be astrong consensusagainst that position outside of the subteam. Subteammembers use their best judgment in taking this step, and the FCP itselfensures there is ample time and notification for stakeholders to pushback if it is made prematurely.
  • For RFCs with lengthy discussion, the motion to FCP is usually preceded byasummary comment trying to lay out the current state of the discussionand major tradeoffs/points of disagreement.
  • Before actually entering FCP,all members of the subteam must sign off;this is often the point at which many subteam members first review theRFC in full depth.
• The FCP lasts ten calendar days, so that it is open for at least 5 businessdays. It is also advertised widely,e.g. inThis Week in Rust. This way allstakeholders have a chance to lodge any final objections before a decisionis reached.
• In most cases, the FCP period is quiet, and the RFC is either merged orclosed. However, sometimes substantial new arguments or ideas are raised,the FCP is canceled, and the RFC goes back into development mode.

Once an RFC becomes "active" then authors may implement it and submit thefeature as a pull request to the Rust repo. Being "active" is not a rubberstamp, and in particular still does not mean the feature will ultimately bemerged; it does mean that in principle all the major stakeholders have agreedto the feature and are amenable to merging it.

Furthermore, the fact that a given RFC has been accepted and is "active"implies nothing about what priority is assigned to its implementation, nor doesit imply anything about whether a Rust developer has been assigned the task ofimplementing the feature. While it is notnecessary that the author of theRFC also write the implementation, it is by far the most effective way to seean RFC through to completion: authors should not expect that other projectdevelopers will take on responsibility for implementing their accepted feature.

Modifications to "active" RFCs can be done in follow-up pull requests. Westrive to write each RFC in a manner that it will reflect the final design ofthe feature; but the nature of the process means that we cannot expect everymerged RFC to actually reflect what the end result will be at the time of thenext major release.

In general, once accepted, RFCs should not be substantially changed. Only veryminor changes should be submitted as amendments. More substantial changesshould be new RFCs, with a note added to the original RFC. Exactly what countsas a "very minor change" is up to the sub-team to decide; checkSub-team specific guidelines for more details.

While the RFC pull request is up, the sub-team may schedule meetings with theauthor and/or relevant stakeholders to discuss the issues in greater detail,and in some cases the topic may be discussed at a sub-team meeting. In eithercase a summary from the meeting will be posted back to the RFC pull request.

A sub-team makes final decisions about RFCs after the benefits and drawbacksare well understood. These decisions can be made at any time, but the sub-teamwill regularly issue decisions. When a decision is made, the RFC pull requestwill either be merged or closed. In either case, if the reasoning is not clearfrom the discussion in thread, the sub-team will add a comment describing therationale for the decision.

Some accepted RFCs represent vital features that need to be implemented rightaway. Other accepted RFCs can represent features that can wait until somearbitrary developer feels like doing the work. Every accepted RFC has anassociated issue tracking its implementation in the Rust repository; thus thatassociated issue can be assigned a priority via the triage process that theteam uses for all issues in the Rust repository.

The author of an RFC is not obligated to implement it. Of course, the RFCauthor (like any other developer) is welcome to post an implementation forreview after the RFC has been accepted.

If you are interested in working on the implementation for an "active" RFC, butcannot determine if someone else is already working on it, feel free to ask(e.g. by leaving a comment on the associated issue).

Some RFC pull requests are tagged with the "postponed" label when they areclosed (as part of the rejection process). An RFC closed with "postponed" ismarked as such because we want neither to think about evaluating the proposalnor about implementing the described feature until some time in the future, andwe believe that we can afford to wait until then to do so. Historically,"postponed" was used to postpone features until after 1.0. Postponed pullrequests may be re-opened when the time is right. We don't have any formalprocess for that, you should ask members of the relevant sub-team.

Usually an RFC pull request marked as "postponed" has already passed aninformal first round of evaluation, namely the round of "do we think we wouldever possibly consider making this change, as outlined in the RFC pull request,or some semi-obvious variation of it." (When the answer to the latter questionis "no", then the appropriate response is to close the RFC, not postpone it.)

The process is intended to be as lightweight as reasonable for the presentcircumstances. As usual, we are trying to let the process be driven byconsensus and community norms, not impose more structure than necessary.

This repository is currently in the process of being licensed under either of:

• Apache License, Version 2.0, (LICENSE-APACHE orhttps://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT orhttps://opensource.org/licenses/MIT)

at your option. Some parts of the repository are already licensed according to those terms. For more seeRFC 2044 and itstracking issue.

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.