RFC: RFC process redux

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.

active/0000-rfc-process.md

@@ -0,0 +1,116 @@
+- Start Date: 2014/03/24
+- RFC PR #: 2
+- 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/