On Tue, May 28, 2019 at 12:46 PM Matt Farina <matt.far...@gmail.com> wrote:
> Let me be a little more clear. In the docs (see the version prior to the > 2018 update at > https://github.com/golang/proposal/tree/a16a937b3b39c4c42f063842407c30c4c451b524#process) > there was no documentation on the proposal reviewers on the Go team. How > proposals were reviewed was not *documented*. Numerous people, myself > included, found this by seeing comments on issues that referred to this > group. Saying something in a speech at a Gothercon is not documentation. > People who were not paying attention, were not there, or forgot we also not > able to come upon this information. > > This is why I referred to it not being documented publicly. > The first commit <https://github.com/golang/proposal/commit/01029b917fbbfcf1cbf53df42c8c3f48da9ffe7d#diff-04c6e90faac2675aa89e2176d2eec7d8> of the proposal repo's README.md in 2015 had links to these talks: To learn more about Go's origins and development process, see the talks [How Go Was Made](http://talks.golang.org/2015/how-go-was-made.slide), [The Evolution of Go]( http://talks.golang.org/2015/gophercon-goevolution.slide), and [Go, Open Source, Community](http://blog.golang.org/open-source) from GopherCon 2015. More importantly, that initial README also lays out the proposal process, which aims to structure a community discussion that leads to overall consensus, not a judgement from a supreme court of Go. In 2016 we realized that we needed to document what happens when consensus cannot be reached but we still have to move forward, and we did that. That version said: Once comments and revisions on the design doc wind down, there is a final discussion about the proposal. The goal of the final discussion is to reach agreement on the next step: (1) accept or (2) decline. The discussion is expected to be resolved in a timely manner. If clear agreement cannot be reached, the arbiter (rsc@) reviews the discussion and makes the decision to accept or decline. That last line is the last resort. And I wanted to make clear that even then I am discussing that discussion carefully and thoughtfully with others rather than just flying solo. So I added the text about the proposal review group in 2018. That text emphasizes first that proposal review is mainly about facilitating discussions: *Proposal Review* A group of Go team members holds “proposal review meetings” approximately weekly to review pending proposals. The principal goal of the review meeting is to make sure that proposals are receiving attention from the right people, by cc'ing relevant developers, raising important questions, pinging lapsed discussions, and generally trying to guide discussion toward agreement about the outcome. The discussion itself is expected to happen on the issue tracker, so that anyone can take part. The proposal review meetings also identify issues where consensus has been reached and the process can be advanced to the next step (by marking the proposal accepted or declined or by asking for a design doc). And then it also elaborates on the last-resort decision-making to make clear that even if we can't get to consensus among all the people commenting on the issue, we still try to find a decision that all the proposal reviewers agree is appropriate (that is, I don't just do whatever I want): *Consensus and Disagreement* 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 even consensus among the proposal review group cannot be reached (which would be exceedingly unusual), the arbiter (rsc@) reviews the discussion and decides the next step. It has never happened that the proposal review group was unable to agree about the next step for a given issue. The number of issues that even get that far is very small too. The vast majority have a clear outcome. > I think this highlights a documentation gap or place where people have > different understandings. Is the organizational hierarchy of Go documented > somewhere? Lots of phrases are thrown around and different people can throw > different meanings on them. When I refer to that group I'm thinking of > things like the Kubernetes Steering Committee. It is the core set of people > responsible for the decisions on the project. This is a smaller group than > the committers. It is the decision/direction makers for the project. > > This group, as far as I'm aware, is all Googlers. It may not be documented > and there may be assumptions. This is what I expect from a company run > project. > As you noted, years ago I used to sign things by mentioning @golang/proposal-review, to try to make transparent who the review group was. Then it was pointed out to me that GitHub doesn't let people outside the golang org see the membership list, so I stopped. (If anyone knows how to make the membership 100% public in GitHub settings I would gladly do it. My options are "Secret" and "Visible" and it is set to "Visible".) But FWIW, my understanding is that because you, @mattfarina, are in the golang org, you should be able to see it at https://github.com/orgs/golang/teams/proposal-review/members. It is not all Google employees working on Go. The review group started out as Andrew Gerrand and Brad Fitzpatrick (who started the proposal process) and Robert Griesemer, Ian Lance Taylor, and Rob Pike (who started Go). I replaced Andrew when he wanted to step back. We've since added Andy Bonventre, our lead for the subteam focused specifically on the open source, and Steve Francia, our product manager. And we added Peter Weinberger, because he knows an incredible amount about computing generally and helps us reach better decisions. Again, we spend the bulk of our time making sure the discussions are proceeding well, not being the deciders of last resort. Best, Russ -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAA8EjDSDKpwgQHMnCzREW4L_tL9U5AumhOSg_m8aX1G0Q8%2BHVg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
