[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Condorcet Voting and Supermajorities (Re: [CONSTITUTIONAL AMENDMENT] Disambiguation of 4.1.5)

On Tue, Nov 21, 2000 at 11:38:36AM -0600, Norman Petry wrote:
> Therefore, provided a good compromise is proposed by someone, there should
> never be any radical changes in policy, merely gradual evolution.  In this
> case, supermajority requirements simply undermine the democratic character
> of an organisation, by giving the supporters of the status quo much more
> political power than those who prefer change.

I'm not sure this is an ideal way of looking at things from Debian's
perspective. The usual decision making process in Debian is (supposed
to be) one of reaching consensus on an issue, not one of democracy,
per se.  I tend to look at consensus as an attempt to disenfrachise
(by ignoring their objections) no one, and voting as an attempt to
disenfranchise up to 50% of the people concerned (and dictatorship
as an attempt to disenfranchise everyone else but one). If consensus
building is successful, then there's no need for a vote, because it's
clear everyone will vote the same way, and all is well.

But even if we've given up on satisfying everyone, it still seems
appropriate to try satisfying 75% or 66% of people rather than 50%
of people for some issues.

Note that this is why I think "further discussion" is a better result
than "no" when the most popular result (which has majority support
of all alternatives, including both no and further discussion) doesn't
succeed because of supermajority requirements: were "no" to win, you'd be
disenfranchising up to 66% or 75% of people. At least further discussion
gives these people (the majority of Debian, essentially) a chance to work
out a more acceptable form of their proposal and repropose it later [0].

> Obviously, votes on general resolutions (which require a simple majority)
> cannot be combined with constitutional amendments that require a
> supermajority, since the different majority requirements make it impossible
> to compare them.

It actually seems quite easy to compare them: you count the votes that
prefer one to the other, and the votes that prefer the other to the one,
and the one with the more votes is the preferred one.

> This is true even if they both address the same issues in
> different ways.  If a constitutional amendment is proposed, the Secretary
> should require any other counter-proposals or amendments to *also* be worded
> as constitutional amendments, or else rule them out of order.  Of course, if
> these counter-proposals do not require constitutional changes, they can be
> proposed later as ordinary GRs

This just encourages people to vote for "further discussion" because
they can't vote for what they actually want to happen, especially if what
they want requires a constitutional amendment. If they're really upset about
the way non-free works at the moment, and want to vote:

	[1] Move non-free to unofficial.debian.org
	[2] Remove non-free
	[3] Further discussion
	[ ] Keep non-free

but their current ballot only contains (and can only contain):

	[ ] Remove non-free
	[ ] Keep non-free
	[ ] Further discussion

should they rank further discussion first (since they'd like further
discussion to happen so they can propose a new ballot that contains the
option they want?), or should they vote for keep non-free (since you have
to keep non-free if you want to stick it on some other server), or what?
Should they keep going around with different votes (no, we can't vote
for the 3:1 majority vote, so vote for further discussion; okay, that
failed, let's try a 1:1 majority vote on what we want, oh that failed
too; better try the 3:1 majority one again and vote properly this time,
aha! it succeeded)?

It seems perfectly meaningful to prefer unofficial.debian.org to removing
non-free, so it seems a poor choice to make that preference inexpressible
just for procedural reasons.

> I've noticed that there is a tendency among participants on debian-vote to
> propose solutions which 'serialise' decision-making, rather than using using
> the existing mechanisms.  I think this is a result of people's experience
> with organisations which use Robert's Rules of Order. 

Actually, it's only happened once, when I amended John's proposal: all
our other votes (the logo vote is a prime example) have just been one
vote [1].  The reason the previous vote was going to be split into two: a
vote on the form of the GR (ie, whether my amendment should be accepted),
and a vote on whether the GR should succeed (yes/no/further discussion),
is because that's the only procedure defined in the constitution for
offering any sort of alternative. Nobody actually *likes* all the copious
votes we seem to have. That I've seen, anyway.


[0] Presumably they wouldn't be annoying enough to just keep proposing the
    exact same alternatives, since presumably the vote would go the same way
    (or even worse, if people are annoyed enough to change their vote). So
    general resolution terrorism doesn't seem too likely.

[1] Actually, the logo vote might not be the best example, since it was
    followed by a "swap logo" vote, rather than having the swapped logo
    included in the original vote.

Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

     ``Thanks to all avid pokers out there''
                       -- linux.conf.au, 17-20 January 2001

Attachment: pgpe2SmT5ooKA.pgp
Description: PGP signature

Reply to: