Adjust the evolution process based on experience. (#764)

Recent experience indicates that the system of thumbs-up doesn't seem to
work consistently. Replace it with more broad encouragement to use PR
reactions to surface sentiment and a judgement call by the leads on when
a proposal is ready to merge.

An explicit goal here is that leads can make this judgement call
reflecting the nature of the proposal. Many of these are low-risk.
Either they are easily fixed-forward or minimally disruptive. This can
be because they are merely beginning to fill out a largely open area, or
because they are minor changes.

Also try to clarify that it is expected for the leads to sometimes miss
things or make mistakes, and encourage a revert or fix-forward mentality
rather than slowing down progress to reduce the rate of mistakes.

docs/project/evolution.md

@@ -37,11 +37,14 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 ## Overview
 
 Carbon's evolution process uses [proposals](#proposals) to evaluate and approve
-significant changes to the project or language. The goal is to ensure these
-kinds of changes can receive feedback from the entire community, and also to
-resolve questions and decide direction efficiently. We use proposals to create a
-clear log of rationale for why the project and language have evolved in
-particular directions.
+[significant changes](#when-to-write-a-proposal) to the project or language.
+This process is designed to:
+
+-   Ensure these kinds of changes can receive feedback from the entire
+    community.
+-   Resolve questions and decide direction efficiently.
+-   Create a clear log of rationale for why the project and language have
+    evolved in particular directions.
 
 When there are questions, concerns, or issues with a proposal that need to be
 resolved, Carbon uses its [governance](#governance-structure) system of
@@ -57,9 +60,6 @@ language are well explained, justified, and reviewed by the community.
 
 ### Life of a proposal
 
--   We author and review proposals when making
-    [substantive changes to Carbon](#when-to-write-a-proposal).
-
 -   Proposals consist of a PR (pull request) in GitHub that adds a document to
     the [`proposals/` directory](/proposals/) following
     [the template](/proposals/template.md).
@@ -76,27 +76,31 @@ language are well explained, justified, and reviewed by the community.
     -   This also signifies an RFC (request for comment) from the entire
         community.
 
--   Contributors should react with a _thumbs-up_ to the proposal PR if they are
-    generally interested and supportive of the high level direction based on
-    title and summary.
+-   Contributors are encouraged to react with a _thumbs-up_ to proposal PRs if
+    they are generally interested and supportive of the high level direction
+    based on title and summary. Similarly, other reactions are encouraged to
+    help surface contributor's sentiment.
 
 -   We use GitHub issues to discuss and track _blocking issues_ with proposals,
     such as open questions or alternative approaches that may need further
     consideration. These are assigned to carbon-leads to decide.
 
--   The lead assigned to review the PR should ensure that at least three
-    contributors (possibly including the lead) are generally supportive and
-    react with thumbs-up. If a proposal doesn't have these thumbs-up, the leads
-    together need to decide whether to move forward, and if so provide those
-    thumbs-up.
+-   A [Carbon lead](#carbon-leads-1) will be assigned to a proposal PR. They are
+    responsible for the basic review (or delegating that) as well as ultimately
+    approving the PR.
 
--   If the leads choose to defer or reject the proposal, the reviewing lead
-    should explain why and close the PR.
+-   The assigned lead should ensure that there is a reasonable degree of
+    consensus among the contributors outside of the identified blocking issues.
+    Contributors should have a reasonable chance to raise concerns, and where
+    needed they should become blocking issues. Community consensus isn't
+    intended to be perfect though, and is ultimately a judgement call by the
+    lead. When things are missed or mistakes are made here, we should just
+    revert or fix-forward as usual.
 
--   Once the thumbs-up are present and the assigned lead finishes code review,
-    the lead should [approve](/docs/project/code_review.md#approving-the-change)
-    the PR. Any outstanding high-level concerns should be handled with blocking
-    issues.
+-   Once a reasonable degree of community consensus is reached and the assigned
+    lead finishes code review, the lead should
+    [approve](/docs/project/code_review.md#approving-the-change) the PR. Any
+    outstanding high-level concerns should be handled with blocking issues.
 
 -   Optionally, the assigned lead can file a blocking issue for a one week final
     comment period when they approve. This is rarely needed, and only when it is
@@ -110,6 +114,9 @@ language are well explained, justified, and reviewed by the community.
 -   The proposal PR can be merged once the assigned lead approves, all blocking
     issues have been decided, and any related decisions are incorporated.
 
+-   If the leads choose to defer or reject the proposal, the reviewing lead
+    should explain why and close the PR.
+
 ### Proposal roles
 
 It is also useful to see what the process looks like for different roles within
@@ -212,8 +219,9 @@ Everyone actively contributing to the evolution of Carbon should try to
 regularly:
 
 -   Give a thumbs-up or other reaction on any interesting PRs out for RFC to
-    help surface general enthusiasm for the high level idea or direction. Don't
-    worry about "approving" or the details here.
+    help surface the community's sentiment around the high level idea or
+    direction. Don't worry about "approving" or the detailed text of the
+    proposal here.
 
 -   If interested and time permitting, dive into some RFCs and provide
     [community feedback](#community).
@@ -237,8 +245,15 @@ ensuring proposal PRs land:
     -   Escalate any blocking issues without a resolution that are slowing down
         the proposal to the other leads.
 
-    -   Evaluate whether an extended final comment period is important for the
-        community given the nature of the proposal.
+    -   Evaluate whether the community has had a reasonable chance to raise
+        concerns and there is sufficient consensus to move forward given the
+        decisions on the blocking issues. This doesn't need to be perfect
+        though. Here too, we prioritize progress over perfection. We can revert
+        or fix-forward mistakes whenever necessary, especially for low-risk
+        changes. In rare cases, an extended final comment period can be used
+        when warranted for a proposal.
+
+    -   Once ready, approve and help the author merge the proposal.
 
 ### When to write a proposal