Minor changes

Author: nrc

README.md

@@ -199,7 +199,9 @@ and the RFC seems to be in a steady state, the shepherd and/or sub-team leader
 will announce an FCP. In general, the idea here is to "front-load" as much of
 the feedback as possible before the point where we actually reach a decision -
 by the end of the FCP, the decision on whether or not to accept the RFC should
-be obvious from the RFC discussion thread.
+usually be obvious from the RFC discussion thread. On occasion, there may not be
+consensus but discussion has stalled. In this case, the relevant team will make
+a decision.
 
 
 ## The RFC life-cycle
@@ -248,9 +250,9 @@ posted back to the RFC pull request.
 A sub-team makes final decisions about RFCs after the benefits and drawbacks are
 well understood. These decisions can be made at any time, but the sub-team will
 regularly issue decisions. When a decision is made, the RFC PR will either be
-merged or closed, in either case with a comment describing the rationale for the
-decision. The comment should largely be a summary of discussion already on the
-comment thread.
+merged or closed. In either case, if the reasoning is not clear from the
+discussion in thread, the sub-team will add a comment describing the rationale
+for the decision.
 
 
 ## Implementing an RFC

compiler_changes.md

@@ -26,7 +26,12 @@ submitted later if there is scope for large changes to the language RFC.
   non-trivial ways
 * Adding, removing, or changing a stable compiler flag
 * The implementation of new language features where there is significant change
-  or addition to the compiler
+  or addition to the compiler. There is obviously some room for interpretation
+  about what consitutes a "significant" change and how much detail the
+  implementation RFC needs. For guidance, [associated items](text/0195-associated-items.md)
+  and [UFCS](text/0132-ufcs.md) would clearly need an implementation RFC,
+  [type ascription](text/0803-type-ascription.md) and
+  [lifetime elision](text/0141-lifetime-elision.md) would not.
 * Any other change which causes backwards incompatible changes to stable
   behaviour of the compiler, language, or libraries
 

libs_changes.md

@@ -27,8 +27,7 @@
       at this point in time can still mean major community breakage regardless of trains,
       however.
     * HOWEVER: Big PRs can be a lot of work to make only to have that work rejected for
-      details that could have been hashed out first. *This is the motivation for
-      having RFCs*.
+      details that could have been hashed out first.
 
 * RFCs are *only* meaningful if a significant and diverse portion of the
 community actively   participates in them. The official teams are not
@@ -95,10 +94,10 @@ current implementation.
 * Once something has been merged as unstable, a shepherd should be assigned
   to promote and obtain feedback on the design.
 
-* Once the API has been unstable for at least one full cycle (6 weeks),
-  the shepherd (or any library sub-team member) may nominate an API for a
-  *final comment period* of another cycle. Feedback and other comments should be
-  posted to the tracking issue. This should be publicized.
+* Every time a release cycle ends, the libs teams assesses the current unstable
+  APIs and selects some number of them for potential stabilization during the
+  next cycle. These are announced for FCP at the beginning of the cycle, and
+  (possibly) stabilized just before the beta is cut.
 
 * After the final comment period, an API should ideally take one of two paths:
   * **Stabilize** if the change is desired, and consensus is reached