Skip to content

Commit a260073

Browse files
brsonbrson
committed
Merge pull request #6 from brson/rfc
RFC: RFC process redux
2 parents 14ca6f6 + f69e96c commit a260073

File tree

2 files changed

+120
-0
lines changed

2 files changed

+120
-0
lines changed

‎0000-template.md

+4
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,7 @@
1+
- Start Date: (fill me in with today's date, YYY-MM-DD)
2+
- RFC PR #: (leave this empty)
3+
- Rust Issue #: (leave this empty)
4+
15
# Summary
26

37
One para explanation of the feature.

‎active/0001-rfc-process.md

+116
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,116 @@
1+
- Start Date: 2014-03-11
2+
- RFC PR #: 2, 6
3+
- Rust Issue #: N/A
4+
5+
# Summary
6+
7+
The "RFC" (request for comments) process is intended to provide a
8+
consistent and controlled path for new features to enter the language
9+
and standard libraries, so that all stakeholders can be confident about
10+
the direction the language is evolving in.
11+
12+
# Motivation
13+
14+
The freewheeling way that we add new features to Rust has been good for
15+
early development, but for Rust to become a mature platform we need to
16+
develop some more self-discipline when it comes to changing the system.
17+
This is a proposal for a more principled RFC process to make it
18+
a more integral part of the overall development process, and one that is
19+
followed consistently to introduce features to Rust.
20+
21+
# Detailed design
22+
23+
Many changes, including bug fixes and documentation improvements can be
24+
implemented and reviewed via the normal GitHub pull request workflow.
25+
26+
Some changes though are "substantial", and we ask that these be put
27+
through a bit of a design process and produce a consensus among the Rust
28+
community and the [core team].
29+
30+
## When you need to follow this process
31+
32+
You need to follow this process if you intend to make "substantial"
33+
changes to the Rust distribution. What constitutes a "substantial"
34+
change is evolving based on community norms, but may include the following.
35+
36+
- Any semantic or syntactic change to the language that is not a bugfix.
37+
- Changes to the interface between the compiler and libraries,
38+
including lang items and intrinsics.
39+
- Additions to `std`
40+
41+
Some changes do not require an RFC:
42+
43+
- Rephrasing, reorganizing, refactoring, or otherwise "changing shape
44+
does not change meaning".
45+
- Additions that strictly improve objective, numerical quality
46+
criteria (warning removal, speedup, better platform coverage, more
47+
parallelism, trap more errors, etc.)
48+
- Additions only likely to be _noticed by_ other developers-of-rust,
49+
invisible to users-of-rust.
50+
51+
If you submit a pull request to implement a new feature without going
52+
through the RFC process, it may be closed with a polite request to
53+
submit an RFC first.
54+
55+
## What the process is
56+
57+
In short, to get a major feature added to Rust, one must first get the
58+
RFC merged into the RFC repo as a markdown file. At that point the RFC
59+
is 'active' and may be implemented with the goal of eventual inclusion
60+
into Rust.
61+
62+
* Fork the RFC repo http://github.com/rust-lang/rfcs
63+
* Copy `0000-template.md` to `active/0000-my-feature.md` (where
64+
'my-feature' is descriptive. don't assign an RFC number yet).
65+
* Fill in the RFC
66+
* Submit a pull request. The pull request is the time to get review of
67+
the design from the larger community.
68+
* Build consensus and integrate feedback. RFCs that have broad support
69+
are much more likely to make progress than those that don't receive any
70+
comments.
71+
72+
Eventually, somebody on the [core team] will either accept the RFC by
73+
merging the pull request and assigning the RFC a number, at which point
74+
the RFC is 'active', or reject it by closing the pull request.
75+
76+
Whomever merges the RFC should do the following:
77+
78+
* Assign a sequential id.
79+
* Add the file in the active directory.
80+
* Create a corresponding issue on Rust.
81+
* Fill in the remaining metadata in the RFC header, including the original
82+
PR # and Rust issue #.
83+
* Commit everything.
84+
85+
Once an RFC becomes active then authors may implement it and submit the
86+
feature as a pull request to the Rust repo. An 'active' is not a rubber
87+
stamp, and in particular still does not mean the feature will ultimately
88+
be merged; it does mean that in principle all the major stakeholders
89+
have agreed to the feature and are amenable to merging it.
90+
91+
Modifications to active RFC's can be done in followup PR's. An RFC that
92+
makes it through the entire process to implementation is considered
93+
'complete' and is moved to the 'complete' folder; an RFC that fails
94+
after becoming active is 'inactive' and moves to the 'inactive' folder.
95+
96+
# Alternatives
97+
98+
Retain the current informal RFC process. The newly proposed RFC process is
99+
designed to improve over the informal process in the following ways:
100+
101+
* Discourage unactionable or vague RFCs
102+
* Ensure that all serious RFCs are considered equally
103+
* Give confidence to those with a stake in Rust's development that they
104+
understand why new features are being merged
105+
106+
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.
107+
108+
# Unresolved questions
109+
110+
1. Does this RFC strike a favorable balance between formality and agility?
111+
2. Does this RFC successfully address the aforementioned issues with the current
112+
informal RFC process?
113+
3. Should we retain rejected RFCs in the archive?
114+
115+
[core team]: https://github.com/mozilla/rust/wiki/Note-core-team
116+
[PEP]: http://legacy.python.org/dev/peps/pep-0001/

0 commit comments

Comments
 (0)