From 68e3dee1770c40ea8300c6691d4b3cd5161a1fe3 Mon Sep 17 00:00:00 2001 From: Ben Striegel Date: Tue, 11 Mar 2014 22:24:51 -0400 Subject: [PATCH 1/3] RFC: The Rust RFC Process --- active/0000-rfc-process.md | 87 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 87 insertions(+) create mode 100644 active/0000-rfc-process.md diff --git a/active/0000-rfc-process.md b/active/0000-rfc-process.md new file mode 100644 index 00000000000..94f74f00445 --- /dev/null +++ b/active/0000-rfc-process.md @@ -0,0 +1,87 @@ +# 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. + +Goals of the specified RFC process: + +* Discourage unactionable or vague RFCs +* Ensure that all serious RFCs are considered equally +* Those with a stake in Rust's development should feel confident they +understand why new features are being merged + +# 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]. + +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. + +## 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. + +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. + +[core team]: https://github.com/mozilla/rust/wiki/Note-core-team From 039c2cfc8a15297ea27d1d070c0258b8c51fb89c Mon Sep 17 00:00:00 2001 From: Ben Striegel Date: Tue, 11 Mar 2014 23:41:01 -0400 Subject: [PATCH 2/3] Added missing RFC sections --- active/0000-rfc-process.md | 33 ++++++++++++++++++++++++++------- 1 file changed, 26 insertions(+), 7 deletions(-) diff --git a/active/0000-rfc-process.md b/active/0000-rfc-process.md index 94f74f00445..6bcd8ed25ef 100644 --- a/active/0000-rfc-process.md +++ b/active/0000-rfc-process.md @@ -1,3 +1,10 @@ +# Summary + +Fork the RFC repo, copy the provided template RFC into the "active" directory +with a descriptive name, fill out each section, and submit as a pull request +for review. Advertise the proposed RFC and work to gain a consensus. Once +approved and merged, RFCs become fair game for implementors. + # Motivation The freewheeling way that we add new features to Rust has been good for @@ -7,13 +14,6 @@ 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. -Goals of the specified RFC process: - -* Discourage unactionable or vague RFCs -* Ensure that all serious RFCs are considered equally -* Those with a stake in Rust's development should feel confident they -understand why new features are being merged - # Detailed design Many changes, including bug fixes and documentation improvements can be @@ -84,4 +84,23 @@ 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 adress the aforementioned issues with the current + informal RFC process? + [core team]: https://github.com/mozilla/rust/wiki/Note-core-team +[PEP]: http://legacy.python.org/dev/peps/pep-0001/ From 616d2be9e40aa7e96c69f09b4b2eaf8976c06951 Mon Sep 17 00:00:00 2001 From: Ben Striegel Date: Tue, 11 Mar 2014 23:43:20 -0400 Subject: [PATCH 3/3] Typo --- active/0000-rfc-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/active/0000-rfc-process.md b/active/0000-rfc-process.md index 6bcd8ed25ef..d0acdb41840 100644 --- a/active/0000-rfc-process.md +++ b/active/0000-rfc-process.md @@ -99,7 +99,7 @@ As an alternative alternative, we could adopt an even stricter RFC process than # Unresolved questions 1. Does this RFC strike a favorable balance between formality and agility? -2. Does this RFC successfully adress the aforementioned issues with the current +2. Does this RFC successfully address the aforementioned issues with the current informal RFC process? [core team]: https://github.com/mozilla/rust/wiki/Note-core-team