On 27.05.20 16:13, Richard Hartmann wrote: > On Wed, May 27, 2020 at 12:54 AM Bjoern Rabenstein <[email protected]> wrote: > > > - The changes as suggested in > > > > https://github.com/prometheus/docs/commit/f7ee6ac5a9b841be6be25d92e2c403de15949491 > > are _not_ following the spirit of RFC7282. > > I disagree with the above, and with the longer-form text not quoted, as > * rough consensus obviously tries to go the happy path of full consensus first
Weird. My reading is that "obviously" rough consensus is what you do if you cannot reach "smooth" consensus but want to avoid voting. > * rough consensus as per the commit contains its mechanisms strictly > below the stronger mechanisms of majority and supermajority vote So you are saying that, if you say "rough consensus", you mean a wider concept around the idea of rough consensus, as described in RFC7282, and not just rough consensus itself as a step during decision making. > > - To truly adopt rough consensus, we need to introduce a chair and get > > rid of decision finding by voting (with change of governance, > > admitting and removing team members, and electing the chair as > > notable exceptions). But that would be a very invasive change of the > > governance. > > If "truly adopting rough consensus" was the proposal, I would agree. > That's _not_ the proposal, though. OK, but then the proposal is really difficult to understand. You don't want to adopt RFC7282 completely, but you also say that "rough consensus" is a whole method or procedure and more than just one step during decision making. I'd say we need a proper definition then and not just a link to RFC7282, of which some parts are relevant and some not, and the reader has to guess which are which. > The proposal is to improve the self-contained "consensus" bit while > keeping both voting mechanisms intact. As such, there's an easy way > out of any impassé. If you want to give a clearer definition of "consensus", fine. So far, things have just become less clear to me. > * consensus: > * 100% agreement by team members who care to join the discussion That's not how I understand consensus. As I have learned much earlier, consensus may include many flavors of disagreement. "Disagree but commit" is perhaps the strongest (and arguably a borderline case). The excellent RFC7282 describes many other "good" varieties of consensus (but that's not the first time I read about them). Example quotes: "Consensus doesn't require that everyone is happy and agrees that the chosen solution is the best one. Consensus is when everyone is sufficiently satisfied with the chosen solution, such that they no longer have specific objections to it." "Coming to consensus is when everyone (including the person making the objection) comes to the conclusion that either the objections are valid, and therefore make a change to address the objection, or that the objection was not really a matter of importance, but merely a matter of taste." It also describes varieties of "not really consensus": "People might very well agree that a solution is sufficient and have no objection to it, but if they also don't actively think it's a good and correct outcome, it's absurd to declare that the group has consensus." Or the "capitulation" antipattern, when one party just has "simply given up by trying to appease the others". or the "horse-trading" variety. Note that none of the consensus examples above, neither the proper ones nor the false ones, are called "rough consensus" in the RFC: "Of course, coming to full consensus like that does not always happen. That's why in the IETF, we talk about 'rough consensus'." (Strictly speaking, you could argue that "rough consensus" is the superset of the happy case and the rough case, but it's still very confusing if the governance says "our default way of deciding is rough consensus". It should be "our default way of deciding is by consensus, if need be by a rough one".) Circling back: If all you want is to define "consensus" better, then let's just do it. I can see how the "as long as nobody objects" in the governance can be read as including some of the "not really consensus" cases from RFC7282, but as excluding some of the "proper consensus" cases. Here is a rough suggestion how a minimal governance change could look like: https://github.com/prometheus/docs/commit/66dcf05d9d8fa246ef7c557b4a1978c718455fd2 _However,_ I have no high hopes that such a governance change will on its own change anything in our decision making. For one, I'm confident that most of us were alredy aware that consensus does not equal "100% agreement by team members". Furthermore, as has been said multiple times by now, most of the difficult decision making had its root cause in precisely the problem that not all participants saw their objections addressed. If we cannot agree that all objections have been addressed, and we have no chair that has the power to make that assessment, there will still be no decision. The only situation that would change with adopting "chair-free rough consensus" is the one where everyone involved agrees that all their objections have been addressed, but they still want them to also be accommodated, and that's why they still continue to block the consensus. I would be surprised if we ever had that situation or ever will have. I wouldn't oppose a governance change as the one I have sketched out above, but I don't think it would help beyond emphasizing a spirit that we were already following anyway. -- 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/20200527211950.GE2326%40jahnn.
