The current situation is what I want to avoid with my suggestion.

Short-circuiting discussions directly into votes, potentially after mere
hours, is not healthy for the project long term and likely reflects
frustrations built up over time.

Voting results are also harder to adapt and evolve as they will need new
votes, not just consensus, to change. This might not be a problem in the
two current well-scoped votes at the moment, but it will become one more
and more over time.

While I can understand the underlying motivations for quick voting on ALL
the things I would much prefer to fix the default mechanism, consensus,
over moving to a different one, voting ,as the new default.

On Mon, May 25, 2020, 14:04 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%2BgTb6cnjVAJPyCKY9bCpEcKBqB88sT2Vi7fO4nSiVCAbSg%40mail.gmail.com.

Reply via email to