Server WG Governance

[Miloslav Trmač]

Hello,
2014-04-21 21:08 GMT+02:00 Stephen Gallagher <sgallagh at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140422/00b33be3/attachment.html>