diff --git a/0000-template.md b/0000-template.md index 51b475339e6..321f00b913f 100644 --- a/0000-template.md +++ b/0000-template.md @@ -1,3 +1,7 @@ +- Start Date: (fill me in with today's date, YYY-MM-DD) +- RFC PR #: (leave this empty) +- Rust Issue #: (leave this empty) + # Summary One para explanation of the feature. diff --git a/active/0001-rfc-process.md b/active/0001-rfc-process.md new file mode 100644 index 00000000000..cae5fdedd6e --- /dev/null +++ b/active/0001-rfc-process.md @@ -0,0 +1,116 @@ +- Start Date: 2014-03-11 +- RFC PR #: 2, 6 +- Rust Issue #: N/A + +# Summary + +The "RFC" (request for comments) process is intended to provide a +consistent and controlled path for new features to enter the language +and standard libraries, so that all stakeholders can be confident about +the direction the language is evolving in. + +# Motivation + +The freewheeling way that we add new features to Rust has been good for +early development, but for Rust to become a mature platform we need to +develop some more self-discipline when it comes to changing the system. +This is a proposal for a more principled RFC process to make it +a more integral part of the overall development process, and one that is +followed consistently to introduce features to Rust. + +# Detailed design + +Many changes, including bug fixes and documentation improvements can be +implemented and reviewed via the normal GitHub pull request workflow. + +Some changes though are "substantial", and we ask that these be put +through a bit of a design process and produce a consensus among the Rust +community and the [core team]. + +## When you need to follow this process + +You need to follow this process if you intend to make "substantial" +changes to the Rust distribution. What constitutes a "substantial" +change is evolving based on community norms, but may include the following. + + - Any semantic or syntactic change to the language that is not a bugfix. + - Changes to the interface between the compiler and libraries, +including lang items and intrinsics. + - Additions to `std` + +Some changes do not require an RFC: + + - Rephrasing, reorganizing, refactoring, or otherwise "changing shape +does not change meaning". + - Additions that strictly improve objective, numerical quality +criteria (warning removal, speedup, better platform coverage, more +parallelism, trap more errors, etc.) + - Additions only likely to be _noticed by_ other developers-of-rust, +invisible to users-of-rust. + +If you submit a pull request to implement a new feature without going +through the RFC process, it may be closed with a polite request to +submit an RFC first. + +## What the process is + +In short, to get a major feature added to Rust, one must first get the +RFC merged into the RFC repo 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 repo http://github.com/rust-lang/rfcs +* Copy `0000-template.md` to `active/0000-my-feature.md` (where +'my-feature' is descriptive. don't assign an RFC number yet). +* Fill in the RFC +* Submit a pull request. The pull request is the time to get review of +the design from the larger community. +* Build consensus and integrate feedback. RFCs that have broad support +are much more likely to make progress than those that don't receive any +comments. + +Eventually, somebody on the [core team] will either accept the RFC by +merging the pull request and assigning the RFC a number, at which point +the RFC is 'active', or reject it by closing the pull request. + +Whomever merges the RFC should do the following: + +* Assign a sequential id. +* Add the file in the active directory. +* Create a corresponding issue on Rust. +* Fill in the remaining metadata in the RFC header, including the original + PR # and Rust issue #. +* Commit everything. + +Once an RFC becomes active then authors may implement it and submit the +feature as a pull request to the Rust repo. An 'active' is not a rubber +stamp, and in particular still does not mean the feature will ultimately +be merged; it does mean that in principle all the major stakeholders +have agreed to the feature and are amenable to merging it. + +Modifications to active RFC's can be done in followup PR's. An RFC that +makes it through the entire process to implementation is considered +'complete' and is moved to the 'complete' folder; an RFC that fails +after becoming active is 'inactive' and moves to the 'inactive' folder. + +# Alternatives + +Retain the current informal RFC process. The newly proposed RFC process is +designed to improve over the informal process in the following ways: + +* Discourage unactionable or vague RFCs +* Ensure that all serious RFCs are considered equally +* Give confidence to those with a stake in Rust's development that they +understand why new features are being merged + +As an alternative alternative, we could adopt an even stricter RFC process than the one proposed here. If desired, we should likely look to Python's [PEP] process for inspiration. + +# Unresolved questions + +1. Does this RFC strike a favorable balance between formality and agility? +2. Does this RFC successfully address the aforementioned issues with the current + informal RFC process? +3. Should we retain rejected RFCs in the archive? + +[core team]: https://github.com/mozilla/rust/wiki/Note-core-team +[PEP]: http://legacy.python.org/dev/peps/pep-0001/