In general, +10 for a change in this direction, since currently the balance is too much in favor of inaction - it's really easy to veto something, but really hard to unblock it because team-wide votes are high-overhead.
I would also want to understand a bit more specifically how this would work in practice though. E.g. when there are three people arguing one way on an issue, and one person against, and all views have been considered and arguments are turning in circles, can the majority (with respect to that discussion) just go ahead and decide / merge things? I guess in the worst case, when someone feels unheard, they can still call for a team-wide vote, but the cost of calling for that vote would then be carried by the minority, not the majority? So things would be more biased towards action. On Mon, May 25, 2020 at 2:04 PM Richard Hartmann < [email protected]> wrote: > Dear all, > > as most of you know, the Prometheus governance[1] has three levels of > formalized decision making. In increasing order of strength and > requirements, they are: > * Consensus > * Majority vote > * Supermajority vote > > > The consensus definition is taken from CouchDB[2] and goes deeply into > its intention to be lightweight and easy to reverse. Yet, a careful > and literal reading of it enshrines what is factually a veto > mechanism. Vetos are easy to utter but hard to unblock short of voting > or an in-between secondary consensus mechanism we have come to call > "Call for Consensus" on the mailing lists. > > In practice, it sometimes feels as if consensus is heavier a process > than outright voting, an order which goes against the initial > intention behind our governance. > > Contrast this to the IETF definition[3] which is more > formal, but explicitly acknowledges that "Rough consensus is when all > issues are addressed, but not necessarily accommodated". IETF has > decades of experience with highly contentious topics which are, > sometimes, discussed by directly opposed parties. It's important to > note that the IETF rough consensus mechanism presumes the existence of > Chairs, but I think we would not need to rely on such heavyweight > process. > > Personally, I am more used to the IETF definition and have not seen > the CouchDB version seen wide adoption, which is part of the reason > why I adopted rough IETF consensus for the Grafana governance[4] > recently released. > > In order to make Prometheus move more quickly and more smoothly, I > would like to suggest adoption the following change: > > https://github.com/prometheus/docs/commit/f7ee6ac5a9b841be6be25d92e2c403de15949491 > > > Best, > Richard > > [1] https://prometheus.io/governance/ > [2] https://couchdb.apache.org/bylaws.html#lazy > [3] https://tools.ietf.org/html/rfc7282 > [4] https://github.com/grafana/grafana/blob/master/GOVERNANCE.md > > -- > You received this message because you are subscribed to the Google Groups > "Prometheus Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/prometheus-developers/CAD77%2BgRvwnU%2BdFRMQ2n%2Bqf6D0oyej-btzsQYh8LjBV9FJ1a78w%40mail.gmail.com > . > -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YoyX3YesL-R9K34ujYki9jsBfVqQTujWZOMTW%2BTZBrmesQ%40mail.gmail.com.
