On 27 May 00:54, Bjoern Rabenstein wrote: > tl;dr: Oh my... > > I think we have an interesting discussion here, and a lot of valid and > good points were brought up. > > However, I have a concern with Richi's suggestions on a much more > fundamental level. > > I (re-)read https://tools.ietf.org/html/rfc7282 very carefully, and > it's indeed a very insightful document. (If you haven't read it > already, I strongly recommend to do so.) > > I do not see any substantial contradiction between CouchDB-style lazy > consensus and RFC7282, though. Please note that lazy consensus > describes the "happy path", pretty much what RFC7282 sees as the > prefered variety of consensus. Rough consensus, however, kicks in if > no "regular" consensus can be reached. It is dealing with a case where > lazy consensus has already disappeared. In all its essence, it's a > _replacement_ for voting. > > 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". > To analyze the premise of RFC7282 a bit more: > > Two relevant properties of the IETF are: > > 1. They do not vote. (They don't want to, but they also cannot.) > 2. They have chairs. > > Obviously, RFC7282 expresses a lot of reasons why votes are > problematic in general, but it also states that the IETF doesn't even > have the formal requirements for votes as their is no definition of > voting right. > > For Prometheus, the situation is pretty much the oppsite: > > 1. We do vote. (We don't want to, but we can if need be.) > 2. We have no chairs. 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. > I want to emphasize that we do not _like_ votes. They are a last > resort. That's clearly stated in the governance. We probably all agree > with the problems of voting described in RFC7282, but as long as votes > don't happen often, those problems are not very relevant. As also > stated in RFC7282, the IETF has to revert to rough consensus quite > often. If we had to revert to votes very often, I'd agree that we have > a problem. The IETF has work groups with hundreds of people (and many > work groups), while the whole Prometheus team consists of 20 > people. The much larger organization size makes it more likely that no > "smooth" consensus can be found. On the other hand, the larger size > goes along with some hierarchical structures, so there are work groups > with chairs, and the existence of chairs enables rough consensus. With > voting as the last resort, they would devolve into constant votes with > all its problems. So rough consensus is the better way out for them. It is not easy to call a vote. When lazy consensus does not work and we speak about niche feature or single line changes, it is embarrassing to go in public and call a vote for "just" that. > I have to disagree with Richi that rough consensus would work without > chairs. On the contrary, I believe that qualified chairs are the most > critical part of making rough consensus work. (As said by others in > the thread already: Who would otherwise make the binding call when the > rough consensus is reached.) See my previous comment about MAINTAINERS.md. > Or in other words: Rough consensus would solve a problem that we don't > have with means that we don't have, either. > > Having said all that, the mail thread so far shows that there is a > fair amount of dissatisfaction with our decision-making performance so > far. In general, I believe we need to understand and discuss the the > underlying problems better to find a good solution for it. However, > here is my speculation why rough consensus appears appealing to some > of us: Precisely because we all know and feel that frequent voting > would be a problem, we avoid votes, and because we do that, we > compromise on the quality of our consensus, e.g. we shy away from > decisions where a consensus seems hard to find, or some of us > "capitulate" (as fittingly described in RFC7282), or the notion of > "veto power" spreads, and probably more... If that's true, the > problems of voting would indirectly have an effect even if actual > votes are rare. In that case, rough consensus might be a solution, but > note what I pointed out above: It would replace the voting, not the > lazy consensus part AKA we would still first try to find a "smooth" > consenus before we go "rough". And yes, it would require chairs. In > case of the small size of the Prometheus team, one chair would > probably be enough. Prometheus-team would then be the voting body to > elect the chair. But here is the point where I stop my speculation. Yes that joins what I said just before. However it might be difficult to give one person so much "power". I think that we miss a way to achieve consensus _within the scope of a PR/issue_. Voting on the developers mailing list to achieve consensus would be strange if we would do it e.g. for each `Pmaybe` in the Prometheus repository. > Summary of my points (all meant as IMHO, even if stated as facts here): > > - The changes as suggested in > > https://github.com/prometheus/docs/commit/f7ee6ac5a9b841be6be25d92e2c403de15949491 > are _not_ following the spirit of RFC7282. > > - 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. > > - Before we do that, I would prefer to not start a discussion with a > possible solution, but with the problem we are trying to solve. I > think we first have to understand the apparent or actual problems in > decision making much better. Then we are in much better shape to > find a solution. > > -- > 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/20200526225437.GR2326%40jahnn. -- Julien Pivotto @roidelapluie -- 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/20200526231037.GA1432576%40oxygen.
