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". 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. 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. 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.) 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. 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.
