-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: RFC process redux #6
Merged
Merged
Changes from 6 commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
68e3dee
RFC: The Rust RFC Process
bstrie 039c2cf
Added missing RFC sections
bstrie 616d2be
Typo
bstrie 3aa5393
Add a little bit of metadata to template
brson e7c37e5
Tweak the RFC RFC based on feedback
brson 94a0fd1
Address more feedback about RFC process
brson 1289937
Change date format to YYYY-MM-DD
brson f69e96c
RFC RFC is #1
brson File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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/ |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have an extremely strong preference for
YYYY-MM-DD
rather thanYYYY/MM/DD
(orYYY/MM/DD
!). Let's go with the standardised date formats.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seconded. ISO 8601 uses dashes, let's not diverge.