diff options
| author | Russ Cox <rsc@golang.org> | 2023-06-27 21:48:01 -0400 |
|---|---|---|
| committer | Russ Cox <rsc@golang.org> | 2023-06-28 01:57:39 +0000 |
| commit | f87e19c78f5b0633681c1fd669470b675c67653c (patch) | |
| tree | 881deee6bfd88f257854947d436614202e490972 /README.md | |
| parent | 29340ddf434b1f9e2d5c4df805d27f76ed1f203f (diff) | |
| download | go-x-proposal-f87e19c78f5b0633681c1fd669470b675c67653c.tar.xz | |
README: add Go architects
Add "Go architects" to handle cases where proposal review cannot
identify a consensus in the issue discussion.
The proposal review group reviews proposals weekly to help them
through the process. (See
https://github.com/golang/proposal#proposal-review.)
When a proposal does not have a clear outcome but a decision must be
made, the proposal review group also works to reach consensus among
themselves on the answer; that is, they decide the outcome. (See
https://github.com/golang/proposal#consensus-and-disagreement.)
Reviewing proposals and deciding contended proposals are two different
activities that need not be done by exactly the same set of people.
Historically there was significant overlap, and there will likely
always be some overlap, but as time goes on it seems likely that we
may want to formally separate the two activities.
In particular, we may want to add more reviewers, to help the process
move along and scale, but still leave truly contended decisions (which
are fairly rare) to a smaller group. This change to README.md implements
that idea.
Fixes golang/go#33528.
Change-Id: Iaec6d7fc4ff588f057eb5db84a9de548ec4c2b8d
Reviewed-on: https://go-review.googlesource.com/c/proposal/+/506565
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Bypass: Russ Cox <rsc@golang.org>
Diffstat (limited to 'README.md')
| -rw-r--r-- | README.md | 29 |
1 files changed, 21 insertions, 8 deletions
@@ -309,15 +309,28 @@ proposal back to the Active column for consideration at the next proposal review The goal of the proposal process is to reach general consensus about the outcome in a timely manner. -If general consensus cannot be reached, -the proposal review group decides the next step -by reviewing and discussing the issue and -reaching a consensus among themselves. +If proposal review cannot identify a general consensus +in the discussion of the issue on the issue tracker, +the usual result is that the proposal is declined. +It can happen that proposal review may not identify a +general consensus and yet it is clear that the proposal +should not be outright declined. +As one example, there may be a consensus that some solution +to a problem is important, but no consensus on which of +two competing solutions should be adopted. -If even consensus among the proposal review group -cannot be reached (which would be exceedingly unusual), -the arbiter ([rsc@](mailto:rsc@golang.org)) -reviews the discussion and decides the next step. +If the proposal review group cannot identify a consensus +nor a next step for the proposal, the decision about the path forward +passes to the Go architects (currently [gri@](mailto:gri@golang.org), +[iant@](mailto:iant@golang.org), and [rsc@](mailto:rsc@golang.org)), +who review the discussion and aim to reach a consensus among themselves. +If so, they document the decision and its rationale on the issue. + +If consensus among the architects cannot be reached, +which is even more unusual, +the arbiter (currently [rsc@](mailto:rsc@golang.org)) +reviews the discussion and decides the next step, +documenting the decision and its rationale on the issue. ## Help |