Re: Draft proposal for resolution process changes
Felix Lechner <felix.lechner@lease-up.com> writes:
> For a committee that effectively appoints its own members, it is
> probably unwise to ask the Chair to resolve split votes except in the
> most trivial of cases. A general vote, on the other hand, would supply
> the broad democratic legitimacy needed to silence critics forever.
> When facing that monumental and often disproportionate alternative,
> some TC members may reconsider their votes. At least I would.
I'm reading this as another message of support for a tied vote in the TC
to result in an outcome of further discussion or to automatically set off
a GR. Let me know if I misunderstood.
I thought about this some more this morning and my concern procedurally is
that this creates a significant incentive for tactical voting.
Specifically, suppose that the technical committee is debating some
topic. Four members support option A, three members support option B, and
the final member would prefer further discussion to either of those
options. There is a 7:1 majority on the committee for taking some action,
either A or B.
If we say that a tie vote either defaults to further discussion or
triggers a GR, the minority of one can vote for option B to force a tie
vote (even though that isn't their true position), which then forces their
desired outcome even though it's not the choice of the other members, or
forces a GR when there may be significant consensus on the TC (options A
and B may differ in only relatively minor matters of wording or timing).
This creates a different version of the sort of problem that this proposal
is designed to prevent. To avoid this in the proposed alternate scheme,
someone in favor of option B would have to vote in favor of A, and it may
not be knowable in advance that this may be necessary. The whole
situation becomes a mess. In contrast, with a casting vote, the most that
the minority of one can do is force the decision to a casting vote,
leaving it to the Chair to decide what the correct outcome should be. And
the Chair can make that decision in the presence of full information about
how everyone voted (so, for instance, may vote against their own previous
vote if it's obvious from the voting results that tactical voting
happened).
It's important to remember here that we cannot get into a casting vote
situation via an up/down vote on a single option. There has to be a
consensus to do something (not further discussion) before this outcome is
possible. In other words, casting votes only come into play if the TC has
already concluded that something proposal should pass and is deciding
between multiple options.
> More generally, foundational documents do not captivate the minds of the
> governed when laden with procedural details. Our constitution already
> shuns a common purpose with "It does not describe the goals of the
> Project" (which for some reason comes right after the more positive "The
> Debian Project is an association of individuals who have made common
> cause to create a free operating system."). In the current thread, I
> miss simple language as to whether the purpose of decisions is
> legitimacy or speed.
I think the constitution is the wrong foundational document to look to for
the "minds of the governed." The constitution is concerned primarily with
the procedural details. We have to spell them out somewhere so that we
have a shared basis to make hard decisions in a way that we've previously
agreed would be fair (even if we're on the losing side).
> I would rely on a simple popular vote when needed (GR, and perhaps
> elections) but otherwise leave the TC to its own devices—including the
> ability to overrule a maintainer with an absolute majority (not 3:1).
> The TC has over the years proven itself to be a trusted and transparent
> institution with good decision-making capabilities. We act better in
> groups and more wisely than as individuals, with or without rules.
The reason for the rework of the TC process in this proposal is precisely
because the TC's decision-making capabilities previously partially broke
down in ways that left a lot of damage behind, including accusations of
unfairness. This proposal would prevent the procedural circumstances that
happened previously from happening again, in a way that I hope is more
transparently fair and predictable than the current process.
More generally, I would encourage everyone to not discount the merits of
having a clear process, even if it feels nit-picky and constraining to
specify one in advance. My experience in multiple heated debates in
Debian, and in similar problems in other governance debates and on-line
communities, is that having good, clear, and previously-agreed process is
exactly what creates the space for people to be gracious and collaborative
even when they strongly disagree with the opinions of others.
If everyone feels they are treated fairly following rules that were known
in advance and aren't changing on the fly to suit the moment, it's easier
to come to terms with simply being outvoted or not agreeing with the rest
of the project. But when the process is unclear or inconsistent or gives
rise to surprises, it's easy to feel like one is being treated unfairly,
which in turn makes it much harder to be gracious in the minority (in part
because it creates doubt that one is truly in the minority).
This unfortunately requires some tedious rules-lawyering in advance to try
to anticipate various contingencies and conflicts which will hopefully
never come to pass. But I think the net long-term effect is to reduce the
temperature.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: