proposal: clarify how proposals are evaluated

[rakyll]

The proposal process document at https://github.com/golang/proposal doesn't mention how the proposals are evaluated/voted. According to the doc, it is a democratic process where the community votes are involved. If the bets are 50-50, there is an arbiter involved. What is document there, imho, is a misleading. The reality is there are certain parties who has more influence in the design and development of the language, hence agreement is critically dependent of the agreement of those parties. Documenting how the process work and how the proposals are evaluated can address the issue reported at #16339 (comment).

/cc @adg @ulikunitz

[bradfitz]

If the bets are 50-50,

Just to be clear: decisions have never been made based on Github reaction vote counts. You saying "50-50" implies there's some counting of votes happening.

With a community as large as Go and Github, there will always be some parties for and against any proposal. And often one side is much more passionate than the other in rallying others to their side.

In the end, the arbiter's job is to weigh the various arguments from both sides and make a decision.

The document currently says that @adg is the arbiter but @adg has been working on some other stuff more lately and doing less day-to-day Go community stuff. I think @rsc (now that he's back) has stepped up as the arbiter.

But yeah, the doc could probably say more to set expectations.

[rakyll]

Just to be clear: decisions have never been made based on Github reaction vote counts. You saying "50-50" implies there's some counting of votes happening.

That's not what I say. From what I read from the linked proposal, expectations are aligning with a voting based system. It might not be clear for those who are contributing their ideas passionately that such a system is neither scalable nor sane for the consistency and the future of the language. Communicating that aspect would be a good addition to the doc.

[s-mang]

+100 to this. The doc makes it seem like the community will reach an eventual agreement/decision, and not the Go team. This is misleading. In asking the community for feedback and documenting that the decision will be made via communal agreement, but then having the Go team (in this case Russ) make the final call will lead to very frustrated, angry, possibly bashing gophers. This has been made apparent by the feedback on the alias declaration proposal after the proposal was accepted.
We don't want this frustration and negativity in our community. We want to reduce the opportunity for creating tension and hostility between gophers as much as possible.
I think just a change in the documentation - more transparency in the process - is a simple way to alleviate this. We need to document that a proposal acts as a venue for community feedback, but the final decision is made by the Go team.
@griesemer @rsc @spf13

[griesemer]

I agree that the document should be more precise about the decision making process; simply to avoid misconceptions and set expectations correctly.

Though I don't see how the document implies a democratic (as in voting-based) process. It just says that there will be a final discussion about the proposal and a decision, possibly made by an arbiter.

In issues where there is overwhelming disagreement, the proposal is declined.
In issues where there is overwhelming agreement, the proposal tends to be accepted.
In highly contentious issues (such as the alias proposal), where agreement and disagreement go hand in hand, the arbiter becomes essential. It makes sense that this arbiter is (a member of) the Go team.

[rakyll]

We can redesign the final phase with additional steps and add clarification to the existing ones:

• The goal of the final discussion is to reach agreement on the next step: (1) accept or (2) decline.
• Once a proposal is filed, it is expected for the Go users to discuss and leave feedback about the proposal.
• The discussion is expected to be resolved in a timely manner.
• An arbiter (a member of the Go team) is responsible to evaluate the proposal and opinions expressed on the proposal to finalize the decision.
• Arbiter accepts or declines the proposal.

[adg]

It's true that neither the intention behind nor the wording of the doc implies a democratic process.

I think it's important to specifically name the arbiter(s). There's no clear definition of the "go team". I sent a CL to s/adg/rsc/. I can't think of anyone more capable or deserving of the role. We should trust him to make the right call, even when we don't agree with it.

I agree with @adams-sarah that this should be made clearer in the proposal docs.

[danp]

In #16339 (comment) a call was made to use GitHub reactions to "express general support or disagreement" which could have caused some confusion over there being some kind of vote. It's not clear if or how those reactions factored into assessing overall support/agreement and disagreement of the linked proposal.

[bradfitz]

@dpiddy, yeah, perhaps that caused confusion. In general we encourage people (via https://golang.org/wiki/NoMeToo and elsewhere) to use Github reactions when they feel compelled to express an emotion but would otherwise drown out constructive discourse with a splattering of "OMG YESS!!@11! +1" comments and/or animated GIF memes.

[rakyll]

@adg, do you want me to send a CL to clarify the proposal doc or do you want to do it yourself? I prefer that you do because you have more background into the process.

[s-mang]

If there's anything I can do to help, I am also happy to.

[adg]

I'll send a CL.

[gopherbot]

CL https://golang.org/cl/29335 mentions this issue.