dnrops
/
rfcs
mirror of https://github.com/rust-lang/rfcs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Tweak the RFC RFC based on feedback

This commit is contained in:
Brian Anderson 2014-03-12 13:52:19 -07:00
parent 3aa5393854
commit e7c37e5356
1 changed files with 20 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
active/0000-rfc-process.md
View File

@ -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/