|
3 | 3 | [Rust RFCs]: #rust-rfcs
|
4 | 4 |
|
5 | 5 | The "RFC" (request for comments) process is intended to provide a consistent
|
6 |
| -and controlled path for changes to Rust (such as new features) so that all |
| 6 | +and controlled path for changes to Rust (such as new features) so that all |
7 | 7 | stakeholders can be confident about the direction of the project.
|
8 | 8 |
|
9 | 9 | Many changes, including bug fixes and documentation improvements can be
|
@@ -136,20 +136,20 @@ merged into the RFC repository as a markdown file. At that point the RFC is
|
136 | 136 | comment period" (FCP), along with a *disposition* for the RFC (merge, close,
|
137 | 137 | or postpone).
|
138 | 138 | - This step is taken when enough of the tradeoffs have been discussed that
|
139 |
| - the subteam is in a position to make a decision. That does not require |
140 |
| - consensus amongst all participants in the RFC thread (which is usually |
141 |
| - impossible). However, the argument supporting the disposition on the RFC |
142 |
| - needs to have already been clearly articulated, and there should not be a |
143 |
| - strong consensus *against* that position outside of the subteam. Subteam |
144 |
| - members use their best judgment in taking this step, and the FCP itself |
145 |
| - ensures there is ample time and notification for stakeholders to push back |
146 |
| - if it is made prematurely. |
| 139 | + the subteam is in a position to make a decision. That does not require |
| 140 | + consensus amongst all participants in the RFC thread (which is usually |
| 141 | + impossible). However, the argument supporting the disposition on the RFC |
| 142 | + needs to have already been clearly articulated, and there should not be a |
| 143 | + strong consensus *against* that position outside of the subteam. Subteam |
| 144 | + members use their best judgment in taking this step, and the FCP itself |
| 145 | + ensures there is ample time and notification for stakeholders to push |
| 146 | + back if it is made prematurely. |
147 | 147 | - For RFCs with lengthy discussion, the motion to FCP is usually preceded by
|
148 | 148 | a *summary comment* trying to lay out the current state of the discussion
|
149 | 149 | and major tradeoffs/points of disagreement.
|
150 | 150 | - Before actually entering FCP, *all* members of the subteam must sign off;
|
151 |
| - this is often the point at which many subteam members first review the RFC |
152 |
| - in full depth. |
| 151 | + this is often the point at which many subteam members first review the |
| 152 | + RFC in full depth. |
153 | 153 | - The FCP lasts ten calendar days, so that it is open for at least 5 business
|
154 | 154 | days. It is also advertised widely,
|
155 | 155 | e.g. in [This Week in Rust](https://this-week-in-rust.org/). This way all
|
|
0 commit comments