proposal: separate proposal review from contended decision-making

[rsc]

The proposal process aims to reach a clear answer by discussion on the GitHub issue. Nearly all the time, it does. Rarely, it does not.

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.

[Freeaqingme]

This sort of reminds me of the Zend Framework CR Team - Community Review Team - for the PHP framework ZF. The focus of the CR Team wasn't only to decide/arbiter on proposed functionality, but also mentor contributors to get their code in shape for the framework.

Initially, these responsibilities were carried out by the Zend team (employees) only. However, as the project grew with more and more proposals (and first time contributors), this became less feasible over time (sounds familiar? :)). Although the CR Team rarely disagreed with the Zend team, it was a good thing nonetheless (imho) that people from different backgrounds were actively (and to some extent, formally) involved in the decision making process.

The idea of the CR Team was raised by the project lead on IRC originally, and later continued on the mailing lists. After an outline of its responsibilities had been defined, an email was put forth on the mailing list for volunteers. The idea was that 5-7 people would join, and (IIRC) 7 people signed up. There wasn't much discussion about who to join, because the contributors who volunteered had been long-term contributors and FOSS oftentimes works best as a meritocracy. After the team was formed the first task of the team was to define its own scope and responsibilities.

I don't want to suggest that the way the ZF CR-Team was set up should be copied or act as a guideline. However, given that there may be some overlap in needs/ideas, I figured I might as well share some of the experiences I had with the ZF project so that perhaps we could pickup some good ideas where they do apply to the Go project.

One concrete suggestion, though, would be to not just think who should be part of this group, but also how (if at all) membership will rotate over time. I think it'd be good to define that (at least partially) upfront.

For more info on the formation of the ZF CR Team:

• https://web.archive.org/web/20100726042510/http://blog.astrumfutura.com/archives/429-Zend-Framework-Community-Review-Team.html
• http://zend-framework-community.634137.n4.nabble.com/Follow-up-regarding-community-review-team-td2246260.html#a2246260

(full disclosure: at the time I was also one of the first members of the ZF CR Team, but haven't been involved with the ZF project for quite a while)

[gopherbot]

Change https://go.dev/cl/506565 mentions this issue: README: add Go architects