From 68e3dee1770c40ea8300c6691d4b3cd5161a1fe3 Mon Sep 17 00:00:00 2001 From: Ben Striegel Date: Tue, 11 Mar 2014 22:24:51 -0400 Subject: [PATCH 1/8] 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/8] 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/8] 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 From 3aa539385407dc73ffe6639c4bff8fc418f1a410 Mon Sep 17 00:00:00 2001 From: Brian Anderson Date: Wed, 12 Mar 2014 13:52:06 -0700 Subject: [PATCH 4/8] Add a little bit of metadata to template --- 0000-template.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/0000-template.md b/0000-template.md index 51b475339e6..54fcb951a8a 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. From e7c37e535665965dcbf92923cf13282857086514 Mon Sep 17 00:00:00 2001 From: Brian Anderson Date: Wed, 12 Mar 2014 13:52:19 -0700 Subject: [PATCH 5/8] Tweak the RFC RFC based on feedback --- active/0000-rfc-process.md | 30 ++++++++++++++++++++---------- 1 file changed, 20 insertions(+), 10 deletions(-) diff --git a/active/0000-rfc-process.md b/active/0000-rfc-process.md index d0acdb41840..a0484aa9d0c 100644 --- a/active/0000-rfc-process.md +++ b/active/0000-rfc-process.md @@ -1,9 +1,13 @@ +- Start Date: 2014/03/24 +- RFC PR #: 2 +- Rust Issue #: N/A + # 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. +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 @@ -23,11 +27,6 @@ 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" @@ -69,10 +68,20 @@ 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 + +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 @@ -101,6 +110,7 @@ As an alternative alternative, we could adopt an even stricter RFC process than 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/ From 94a0fd179cc96e6b2dc535738ba73e630b560c69 Mon Sep 17 00:00:00 2001 From: Brian Anderson Date: Wed, 12 Mar 2014 16:51:57 -0700 Subject: [PATCH 6/8] Address more feedback about RFC process --- active/0000-rfc-process.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/active/0000-rfc-process.md b/active/0000-rfc-process.md index a0484aa9d0c..6aae9d45d17 100644 --- a/active/0000-rfc-process.md +++ b/active/0000-rfc-process.md @@ -1,5 +1,5 @@ -- Start Date: 2014/03/24 -- RFC PR #: 2 +- Start Date: 2014/03/11 +- RFC PR #: 2, 6 - Rust Issue #: N/A # Summary From 128993794330f52fa80c1b6fb58579f92e51644e Mon Sep 17 00:00:00 2001 From: Brian Anderson Date: Thu, 13 Mar 2014 14:34:32 -0700 Subject: [PATCH 7/8] Change date format to YYYY-MM-DD --- 0000-template.md | 2 +- active/0000-rfc-process.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/0000-template.md b/0000-template.md index 54fcb951a8a..321f00b913f 100644 --- a/0000-template.md +++ b/0000-template.md @@ -1,4 +1,4 @@ -- Start Date: (fill me in with today's date, YYY/MM/DD) +- Start Date: (fill me in with today's date, YYY-MM-DD) - RFC PR #: (leave this empty) - Rust Issue #: (leave this empty) diff --git a/active/0000-rfc-process.md b/active/0000-rfc-process.md index 6aae9d45d17..cae5fdedd6e 100644 --- a/active/0000-rfc-process.md +++ b/active/0000-rfc-process.md @@ -1,4 +1,4 @@ -- Start Date: 2014/03/11 +- Start Date: 2014-03-11 - RFC PR #: 2, 6 - Rust Issue #: N/A From f69e96c007d1833e9737f4dcf268b8cb2e31d146 Mon Sep 17 00:00:00 2001 From: Brian Anderson Date: Thu, 13 Mar 2014 14:35:36 -0700 Subject: [PATCH 8/8] RFC RFC is #1 --- active/{0000-rfc-process.md => 0001-rfc-process.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename active/{0000-rfc-process.md => 0001-rfc-process.md} (100%) diff --git a/active/0000-rfc-process.md b/active/0001-rfc-process.md similarity index 100% rename from active/0000-rfc-process.md rename to active/0001-rfc-process.md