-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
At the risk of starting two out-of-control threads in one day, I wanted to bring up a discussion I had with Karsten Wade last week at Red Hat Summit. We were discussing various governance methodologies, specifically that of FESCo, the Board, the WGs and CentOS.
There are some very interesting ideas that the CentOS Board has put into place, the most relevant I think is their mechanism for consensus-based decision-making[1]. I'd like to describe it a little bit here and note how I think in many ways this is pretty much how we in the Server WG have actually been operating thus far and that we may want to actually formalize it.
The short version of the consensus-based voting is that all decisions require that all participants can live with the result and that every member of the voting population (in our case, the nine sitting members of the WG) can block it.
A blocking vote requires a clearly-expressed statement as to why they feel that the choice in question violates the criteria of the project (in our case, it violates our Mission, Vision, PRD or Technical Specification, or that of the Fedora Project at large).
Voting in CentOS requires at least three +1 votes and zero -1 votes for any motion to pass, and with at least 72 hours given for non-present members to express their dissent.[2]
If a blocking vote occurs, this changes the dynamics of the discussion. In traditional majority votes, the result is usually that two "sides" emerge, each trying to swing a sufficient number of the other WG members to their point of view. However, in a consensus-based process, the behavior is that now the remaining members of the group must find a compromise (or correct a misunderstanding) in order to proceed. The benefit here is that the dissenter is treated as someone to work with, rather than to work around.
Karsten also noted that there is a proviso that if one person is truly unable or unwilling to meet in the middle, the rest of the board can, with a unanimous vote, remove a member. So when casting a blocking vote, it becomes paramount to negotiate to the best solution, because failing to do so may carry with it the risk of losing a beneficial member of the group. In essence, a true blocking vote (as opposed to a +0) is saying "I am willing to leave over this; convince me or come to a middle ground".
So, with all that being said, I would like to point out that I think we've actually pretty much done exactly this all along, but without formalizing it. I think the only decision we've ever made (following the creation of the PRD) that had any dissenting votes was over the selection of which database to use as the DB Server Role.
We have so far done an excellent job of reaching consensus (and as a result, I find that our group has managed a pretty excellent working relationship with little bad blood). I'd like to strongly recommend that we formalize this approach, modeled after the CentOS governance. I think that as long as we behave in this way (where consensus is not only desired but mandatory), we will keep this group effective and cordial.
[1] http://www.centos.org/about/governance/appendix-glossary/#consensus-decision...
[2] http://www.centos.org/about/governance/voting/
p.s. Part of this is also driven by my concerns in other groups in Fedora where a tradition of "armed camps" seems to have grown up around all votes.
On Mon, Apr 21, 2014 at 2:08 PM, Stephen Gallagher sgallagh@redhat.com wrote:
At the risk of starting two out-of-control threads in one day, I wanted to bring up a discussion I had with Karsten Wade last week at Red Hat Summit. We were discussing various governance methodologies, specifically that of FESCo, the Board, the WGs and CentOS.
There are some very interesting ideas that the CentOS Board has put into place, the most relevant I think is their mechanism for consensus-based decision-making[1]. I'd like to describe it a little bit here and note how I think in many ways this is pretty much how we in the Server WG have actually been operating thus far and that we may want to actually formalize it.
I think some variation of consensus decision making would be a very nice fit. While I am a pretty big fan of the process in general I'm normally not so fond of using a unaminous voting rule but that is a detail you can think about. Other groups do use other less absolute voting rules, like unanimous - 1, which allows for a small bit of dissent without derailing the decision.
The one abstract concern I have about consensus decision making is that it might tend to water down the difficult decisions that really need to be made at times leaving the governed body with either the status quo or something quite different from what was proposed to begin with.
I'll be watching with great interest as I too have considered proposing something based on consensus decision making for one of the other governance bodies in Fedora.
John
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/21/2014 03:42 PM, inode0 wrote:
On Mon, Apr 21, 2014 at 2:08 PM, Stephen Gallagher sgallagh@redhat.com wrote:
At the risk of starting two out-of-control threads in one day, I wanted to bring up a discussion I had with Karsten Wade last week at Red Hat Summit. We were discussing various governance methodologies, specifically that of FESCo, the Board, the WGs and CentOS.
There are some very interesting ideas that the CentOS Board has put into place, the most relevant I think is their mechanism for consensus-based decision-making[1]. I'd like to describe it a little bit here and note how I think in many ways this is pretty much how we in the Server WG have actually been operating thus far and that we may want to actually formalize it.
I think some variation of consensus decision making would be a very nice fit. While I am a pretty big fan of the process in general I'm normally not so fond of using a unaminous voting rule but that is a detail you can think about. Other groups do use other less absolute voting rules, like unanimous - 1, which allows for a small bit of dissent without derailing the decision.
The problem with that approach (as I see it) is that it doesn't address the marginalization problem. The point of a consensus vote is that it ensures that no member of the group is being ignored (or if they are, it's ultimately because they themselves have refused to meet in the middle). Consensus - 1 still leads to "sides" and just moves the target.
The one abstract concern I have about consensus decision making is that it might tend to water down the difficult decisions that really need to be made at times leaving the governed body with either the status quo or something quite different from what was proposed to begin with.
I'm actually not sure that's a bad thing. If a "hard decision" needs to be made, and the group can't come to consensus about it, that says to me that the decision wasn't fully thought-out. There is always a slight risk that eventually we'll miss out on a major shift, but I'd like to think that the process is sufficiently lightweight that we would be able to return to the question and answer it differently.
And if the result is to get something quite different from the initial proposal, that says to me two things: 1) The initial proposal wasn't good enough and 2) nine intelligent individuals ultimately decided on something they could all live with. Knowing what I know about Fedora Contributors (namely that we are all ultimately on the same side and want to see Fedora and FOSS succeed and thrive), I can't really see any alternative decision going too far afield of what we hope to achieve.
I'll be watching with great interest as I too have considered proposing something based on consensus decision making for one of the other governance bodies in Fedora.
This is the tricky part. A consensus-based model is *very* difficult to shoehorn into the system after the group has been established for a long time. I think we have an opportunity to do so in the Server WG right now because at least so far, we've managed to reach consensus on almost everything anyway; we haven't really had to deal with splitting on major decisions and fighting for swing votes.
But with groups like FESCo, the Board, FPC, etc. (not singling any out), there's a long and entrenched history of majority-based decision-making. The unfortunate side-effect there is that it has on some occasions led to individuals or factions being unable to work together (which is ultimately disfunctional).
I think that if such a system was to be implemented, it really needs to come close to the beginning, before such enmities have formed (or else the effect will likely be that no decisions are ever reached, because neither consensus nor the emergency ban will be possible).
Certainly, if any of those groups want to move towards it anyway, I'd happily support them on it.
As an aside, Karsten has put up a blog post (inspired by this discussion) about the consensus model. I'll shamelessly plug it for him here: http://iquaid.org/2014/04/21/why-consensus-decision-making-is-better-for-ope...
On Mon, Apr 21, 2014 at 2:57 PM, Stephen Gallagher sgallagh@redhat.com wrote:
On 04/21/2014 03:42 PM, inode0 wrote:
On Mon, Apr 21, 2014 at 2:08 PM, Stephen Gallagher sgallagh@redhat.com wrote:
At the risk of starting two out-of-control threads in one day, I wanted to bring up a discussion I had with Karsten Wade last week at Red Hat Summit. We were discussing various governance methodologies, specifically that of FESCo, the Board, the WGs and CentOS.
There are some very interesting ideas that the CentOS Board has put into place, the most relevant I think is their mechanism for consensus-based decision-making[1]. I'd like to describe it a little bit here and note how I think in many ways this is pretty much how we in the Server WG have actually been operating thus far and that we may want to actually formalize it.
I think some variation of consensus decision making would be a very nice fit. While I am a pretty big fan of the process in general I'm normally not so fond of using a unaminous voting rule but that is a detail you can think about. Other groups do use other less absolute voting rules, like unanimous - 1, which allows for a small bit of dissent without derailing the decision.
The problem with that approach (as I see it) is that it doesn't address the marginalization problem. The point of a consensus vote is that it ensures that no member of the group is being ignored (or if they are, it's ultimately because they themselves have refused to meet in the middle). Consensus - 1 still leads to "sides" and just moves the target.
The consensus building process still applies though so the larger group still works with the lone dissenter to build consensus. It just avoids being forced to remove the dissenter in order to proceed from the equation which I think would be quite problematic on a body constructed like the Board for example. And while talking about the application of this to the Board I think it might be more difficult to implement in large part because many issues that come to the Board touch directly on the core values of Fedora and hence call out for principled and in some cases hard line stances.
The one abstract concern I have about consensus decision making is that it might tend to water down the difficult decisions that really need to be made at times leaving the governed body with either the status quo or something quite different from what was proposed to begin with.
I'm actually not sure that's a bad thing. If a "hard decision" needs to be made, and the group can't come to consensus about it, that says to me that the decision wasn't fully thought-out. There is always a slight risk that eventually we'll miss out on a major shift, but I'd like to think that the process is sufficiently lightweight that we would be able to return to the question and answer it differently.
And if the result is to get something quite different from the initial proposal, that says to me two things: 1) The initial proposal wasn't good enough and 2) nine intelligent individuals ultimately decided on something they could all live with. Knowing what I know about Fedora Contributors (namely that we are all ultimately on the same side and want to see Fedora and FOSS succeed and thrive), I can't really see any alternative decision going too far afield of what we hope to achieve.
Yeah, I'm not sure about this concern either. Having not seen this in action in the sort of situations I'm thinking about I just have some concern. You make a good case.
I'll be watching with great interest as I too have considered proposing something based on consensus decision making for one of the other governance bodies in Fedora.
This is the tricky part. A consensus-based model is *very* difficult to shoehorn into the system after the group has been established for a long time. I think we have an opportunity to do so in the Server WG right now because at least so far, we've managed to reach consensus on almost everything anyway; we haven't really had to deal with splitting on major decisions and fighting for swing votes.
But with groups like FESCo, the Board, FPC, etc. (not singling any out), there's a long and entrenched history of majority-based decision-making. The unfortunate side-effect there is that it has on some occasions led to individuals or factions being unable to work together (which is ultimately disfunctional).
I think that if such a system was to be implemented, it really needs to come close to the beginning, before such enmities have formed (or else the effect will likely be that no decisions are ever reached, because neither consensus nor the emergency ban will be possible).
Certainly, if any of those groups want to move towards it anyway, I'd happily support them on it.
In the case of the Board I don't really think it has the history you suggest. I believe for many years and even of late most decisions are not opposed. Even many with some dissent I think we could reach consensus on if we were willing to spend more time doing so. Anyway, thanks for the thoughtful comments and I'll get back out of your way here. Good luck with this if you adopt it.
John
On 21 April 2014 13:57, Stephen Gallagher sgallagh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/21/2014 03:42 PM, inode0 wrote:
On Mon, Apr 21, 2014 at 2:08 PM, Stephen Gallagher
I'll be watching with great interest as I too have considered proposing something based on consensus decision making for one of the other governance bodies in Fedora.
This is the tricky part. A consensus-based model is *very* difficult to shoehorn into the system after the group has been established for a long time. I think we have an opportunity to do so in the Server WG right now because at least so far, we've managed to reach consensus on almost everything anyway; we haven't really had to deal with splitting on major decisions and fighting for swing votes.
But with groups like FESCo, the Board, FPC, etc. (not singling any out), there's a long and entrenched history of majority-based decision-making. The unfortunate side-effect there is that it has on some occasions led to individuals or factions being unable to work together (which is ultimately disfunctional).
I am going to need citations and analysis here. When I was on the board it was very driven by consensus and while there were +5 -4 votes .. the majority of them were not put to a vote until it was clear that a consensus had been reached as best as possible (eg if the vote was +5/-4 then it was taken off the table until it could be improved to being more than just enough to pass.)
The bigger problem is that Fedora is a passion project for many many people who come to it. That brings a lot of emotion and conflict and as much as we can alleviate it.. it is something that we have to realize is always going to be there. If we don't want it to be a passion project any more it is going to take a lot more changing the voting systems
Hello, 2014-04-21 21:08 GMT+02:00 Stephen Gallagher sgallagh@redhat.com:
The short version of the consensus-based voting is that all decisions require that all participants can live with the result and that every member of the voting population (in our case, the nine sitting members of the WG) can block it.
So, first of all: a consensus, when it can be achieved, is a great thing, and looking for it a little harder can often lead to finding better solutions. We *should* be looking for consensus, and have either rules or customs that encourage it. However, I don't think precisely this is it.
If a blocking vote occurs, this changes the dynamics of the discussion. In traditional majority votes, the result is usually that two "sides" emerge, each trying to swing a sufficient number of the other WG members to their point of view.
I think that effect is *good*: it motivates everyone to look just that little more for good arguments for a position, or to refine the discussion to be more precise
The issue is not with having two sides *before* a decision, but with having them *after* a decision. We need all of the group, including the dissenters, to accept the decision and stand behind it in the future together. And that is where the proposed framing (not the mechanism, the mechanism is basically unchanged), IMHO, doesn't work—at least for "technical" decision-making bodies; it might be different for the Board.
Framing as a clear +1/-1 vote explicitly acknowledges, and *encourages*each person voicing their opinion: if an opinion isn't voiced then it can't be voted on; and one may need somewhat of a thick skin to voice a very minority opinion, it can be dealt with quickly and there's no long-term stigma: it's simply "this curious proposal has been voted on and has quickly and decisively lost". Even though it *is* loosing and *feels* like losing, it's explicit and, shall we say, "honest".
It seems to me that framing as a consensus-seeking +1/0 voice tends to *silence* minority/dissenting opinions: once a minority opinion is voiced, the voting body needs to resolve it, and the decision is *delayed* by trying to resolve it. (The "blocking vote" nuclear option is pretty much out of the picture—well, or it is used frequently and then the voting body is completely parallyzed.) At that point, if there is a strong majority opinion, it's no longer a only technical disagreement, it's also a process disagreement: "There's 8 of us clearly agreeing that this is the right thing to do, and now we'll spend a month trying to persuade this crazy person to stop wasting our time.". Therefore, there would be *implied, but not explicit* pressure for the minority to "conform"—and the voting record adds insult to injury, basically saying "these people supported the proposal, and these people *also supported*... passing of the proposal". Not only it *is* loosing and *feels* like losing, it's all being swept under the carpet and the minority can feel "cheated" out of their disagreement, actually poisoning the relationships consensus-seeking was supposed to strengthen.
In addition to the final record hiding the disagreement, the overall incentives do as well: with the pressure on the minority dissenters to conform, they are encouraged to not even voice it ("this is not all that important, if I object now we'll spend a month trying to find something better and then I'll stand aside anyway"), and it could even happen that there is a majority that doesn't like the proposal but won't say anything! Compared to a straight vote, this would add an element of "randomness" to each decision, where the perception of how the group *probably* feels about the issue would affect what opinions are said out loud.
Now, in a sense this is all speculation about framing the facts and dynamics; and while I think these effects would happen, I don't really think they would be very strong (i.e. "poisoning the relationships" would be a slight annoyance but would still make it possible for us to meet in a single room). Technically, the underlying voting system would go through some renaming but would be essentially unchanged:
Voting in CentOS requires at least three +1 votes and zero -1 votes
for any motion to pass, and with at least 72 hours given for non-present members to express their dissent.[2]
Looking *only* at the voting mechanism:
- +1 votes are unchanged. - -1 votes in this proposal = verbally threatening to resign, or resigning over the issue; we have a history of such resignations, so in a sense this is "nothing new"; but building them into a process makes the possibility more prominent, and perhaps implicitly more escalated. - 0 votes in this proposal = -1 votes in our current practice - Quorum decreased from 5 to 3
there's only one real change, decreasing the quorum: in a situation where there are 3 people supporting a proposal, 5 people against a proposal but not willing to resign over it, and no other alternative being proposed, the proposal passes. That seems really unhealthy (... well, and strange, because those 5 people could bring a counterproposal of "do nothing").
So, keeping the quorum of 5 would make much more sense to me, and so would keeping the current naming/framing of the votes (even if actually adopting the "reservations need to be resolved" approach).
But, overall, I'd favor a much weaker mechanism for encouraging consensus-building: I do think it should be easy and painless (both for the author and the group) to propose and refuse a clearly minority opinion. Perhaps something like:
- Any proposal can be approved on a meeting if there is an unanimous agreement of the voting attendees of the meeting (including advance votes by non-attendees). - Any proposal can be approved on a mailing list with an unanimous agreement (all 9 voting members)—or only a smaller quorum, like 7? - All proposals can be approved with a quorum of 5 voting members 4 (5? 6?) days after they have been proposed.
i.e. giving a "cooling off" period to look for a consensus, allow quick decision making when there *is* a consensus, *and* motivating everyone to put proposals on the mailing list instead of only bringing them to the meeting (which has nothing to do with consensus, but would save time during meetings). Mirek
server@lists.fedoraproject.org
-
inode0 -
Miloslav Trmač -
Stephen Gallagher -
Stephen John Smoogen