On 27.05.20 01:10, Julien Pivotto wrote: > On 27 May 00:54, Bjoern Rabenstein wrote: > > > > Thus, if we wanted to introduce rough consensus in our governance, we > > would have to use it instead of the majority vote, not the lazy > > consensus. Replacing the lazy consensus with rough consensus would > > actually be against the spirit of RFC7282 because RFC7282 still > > prefers a "smooth"/"good" consensus over a rough consensus, but > > Richi's proposed change explicitly states that rough consensus is the > > "default decision making mechanism". > > I think that the proposal is more to default to "rfc7282" not "rough > consensus".
Yes, that would make sense, but it's different from what's written in Richi's commit. And it would still mean that votes about technical decisions wouldn't happen anymore (so that that part of the governance needed to be deleted, or in other words: still a way more invasive change than suggested in the commit). > Quoting: > > Although most of the examples in this document talk about working group > chairs, these principles apply to any person who is trying to lead a > group to rough consensus, whether a chair, a design team leader, a > document editor, an area director, or any community member who is > facilitating a discussion or trying to assess consensus. > > I think that could then e.g. fallback to MAINTAINERS.md. One could indeed see Prometheus repos as the equivalent of work groups and their maintainers as the chairs. However, several concerns: - (minor) In case of multiple maintainers, we needed to pick the "real" chair. - (a bit more relevant) The whole prometheus-team is smaller than one work group of the IETF. Do we really want to create the fine-granular hierarchy of an organization with thousands of participants for the 20 people in prometheus-team? (counterpoint: discussions involve more than just prometheus-team, so we arguably have hundreds of potential participants) - (actually very relevant) Most of the controversial choking points in PRs were happening because at least one side of the controversy believed that the change has relevance for the whole project. In which case we are back to square one: Who is actually the person authorized to call the rough consensus? Similarly, we would still not have a chair for all the decisions that are naturally not bound to a particular repository. > Yes that joins what I said just before. However it might be difficult > to give one person so much "power". At least the "parliament" (i.e. prometheus-team) could just elect another chair if the current one goes wild. > I think that we miss a way to achieve consensus _within the scope of a > PR/issue_. See the third of my concerns above. IIRC in the rare cases that the decision of a maintainer of a repo was challenged, one of the justifications was that the implications of the PR/issue in question was believed to reach beyond just that repo. -- Björn Rabenstein [PGP-ID] 0x851C3DA17D748D03 [email] [email protected] -- 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/20200526235134.GV2326%40jahnn.
