Merge pull request rust-lang#190 from pnkfelix/fsk-answer-gabor-questions

Answer Gabor's questions.

Author: brson

README.md

@@ -58,16 +58,92 @@ comments.
 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.
 
+## The RFC life-cycle
+
 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.
+Furthermore, the fact that a given RFC has been accepted and is
+'active' implies nothing about what priority is assigned to its
+implementation, nor does it imply anything about whether a Rust
+developer has been assigned the task of implementing the feature.
+
+Modifications to active RFC's can be done in followup PR's.  We strive
+to write each RFC in a manner that it will reflect the final design of
+the feature; but the nature of the process means that we cannot expect
+every merged RFC to actually reflect what the end result will be at
+the time of the next major release; therefore we try to keep each RFC
+document somewhat in sync with the language feature as planned,
+tracking such changes via followup pull requests to the document.
+
+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.
+
+## Implementing an RFC
+
+Some accepted RFC's represent vital features that need to be
+implemented right away. Other accepted RFC's can represent features
+that can wait until some arbitrary developer feels like doing the
+work. Every accepted RFC has an associated issue tracking its
+implementation in the Rust repository; thus that associated issue can
+be assigned a priority via the [triage process] that the team uses for
+all issues in the Rust repository.
+
+The author of an RFC is not obligated to implement it. Of course, the
+RFC author (like any other developer) is welcome to post an
+implementation for review after the RFC has been accepted.
+
+If you are interested in working on the implementation for an 'active'
+RFC, but cannot determine if someone else is already working on it,
+feel free to ask (e.g. by leaving a comment on the associated issue).
+
+## Reviewing RFC's
+
+Each week the [core team] will attempt to review some set of open RFC
+pull requests.  The choice of pull requests to review is largely
+driven by an informal estimate of whether its associated comment
+thread has reached a steady state (i.e. either died out, or not
+showing any sign of providing feedback improvements to the RFC
+itself). The list of RFC's up for review is posted a week ahead of
+time via standard notification channels (currently the 'rust-dev'
+mailing list as well as the http://discuss.rust-lang.org/ discourse
+site).
+
+We try to make sure that any RFC that we accept is accepted at the
+Tuesday team meeting, with a formal record of discussion regarding
+acceptance.  We do not accept RFC’s at the Thursday triage meeting.
+We may reject RFC’s at either meeting; in other words, the only RFC
+activity on Thursdays is closing the ones that have reached a steady
+state and that the team agrees we will not be adopting.
+
+At both meetings, we try to only consider RFC’s for which at least a
+few participants have read the corresponding discussion thread and are
+prepared to represent the viewpoints presented there. One participant
+should act as a "champion" for the feature.  The "champion" need not
+*personally* desire the feature; they just need to act to represent
+its virtues and the community’s desire for it.
+
+## RFC Postponement
+
+Some RFC pull requests are tagged with the 'postponed' label when they
+are closed (as part of the rejection process).  An RFC closed with
+“postponed” is marked as such because we want neither to think about
+evaluating the proposal nor about implementing the described feature
+until after the next major release, and we believe that we can afford
+to wait until then to do so.
+
+Usually an RFC pull request marked as “postponed” has already passed
+an informal first round of evaluation, namely the round of “do we
+think we would ever possibly consider making this change, as outlined
+in the RFC pull request, or some semi-obvious variation of it.”  (When
+the answer to the latter question is “no”, then the appropriate
+response is to close the RFC, not postpone it.)
+
 
 ### Help this is all too informal!
 
@@ -77,3 +153,4 @@ driven by consensus and community norms, not impose more structure than
 necessary.
 
 [core team]: https://github.com/mozilla/rust/wiki/Note-core-team
+[triage process]: https://github.com/rust-lang/rust/wiki/Note-development-policy#milestone-and-priority-nomination-and-triage