Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: clarify how proposals are evaluated #17129

Closed
rakyll opened this issue Sep 15, 2016 · 12 comments

Comments

@rakyll
Copy link
Member

commented Sep 15, 2016

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

@rakyll rakyll added this to the Unreleased milestone Sep 15, 2016

@bradfitz

This comment has been minimized.

Copy link
Member

commented Sep 15, 2016

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

This comment has been minimized.

Copy link
Member Author

commented Sep 15, 2016

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.

@adams-sarah

This comment has been minimized.

Copy link
Contributor

commented Sep 15, 2016

+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

This comment has been minimized.

Copy link
Contributor

commented Sep 15, 2016

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

This comment has been minimized.

Copy link
Member Author

commented Sep 15, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Sep 15, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Sep 15, 2016

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

This comment has been minimized.

Copy link
Member

commented Sep 15, 2016

@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

This comment has been minimized.

Copy link
Member Author

commented Sep 15, 2016

@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.

@adams-sarah

This comment has been minimized.

Copy link
Contributor

commented Sep 16, 2016

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

@adg adg self-assigned this Sep 16, 2016

@adg

This comment has been minimized.

Copy link
Contributor

commented Sep 16, 2016

I'll send a CL.

@gopherbot

This comment has been minimized.

Copy link

commented Sep 16, 2016

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

@golang golang locked and limited conversation to collaborators Sep 16, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
7 participants
You can’t perform that action at this time.