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

Re: Hybrid Theory

On Sun, Dec 08, 2002 at 09:03:22PM +0100, Jochen Voss wrote:
> > 	(1) We want a voting system that handles quorums.
> > 	(1a) Quorums are handled on a per-option basis.
> > 	(1b) Electors are counted toward the quorum if they vote, and if they
> > 	     rank the option above the default option.
> Can you give reasons for (1a) and (1b)? 

I can't give a reason for (1); quorums in real meetings are used to
make sure enough people are able to participate in decisions for them
to be meaningful.  Since we do everything over mailing lists and have a
couple of weeks for every issue to be considered, I'm not sure there's
any benefit to making sure there are at least a given number of votes.

But on the assumption that there is, then we need to take account of
the differences between Debian's system than real life meetings. First,
in a real life meeting, everyone who's present is counted for a quorum:
they're locked in a room and can't leave afterall, so it doesn't matter
how they vote. For Debian, you don't have any "presence" to count, and
you don't want to discourage people from voting, which means allowing
them to vote in such a way that options they don't like are given no
support whatsoever.

Additionally, this gives us the minimum change from what we have now.

> Some other goal I would propose:
>     (3) In the absence of a quorum/supermajority requirement our
>         voting system should behave identical to textbook Condorcet
>         voting with Cloneproof Schwartz sequential dropping.
> This may be clear (is it?) but I think that some of the
> previous drafts did not have this property.

It's irrelevant, we don't have votes without quorum/supermajority

Note that as stated our votes are a combination of approval and Condorcet
voting: an option is "approved" by the number of ballots that rank it
above the default option.

One way to think about this is to say:

	(1) First we use approval voting to handle the default option,
	    quorum and supermajority. An option is "approved" by the
	    number of votes that rank it above the default option. An
	    option is "disapproved" by the number of votes that rank it
	    below the default option.

	    If an option is approved by fewer votes than its quorum, it
	    is dropped.

	    If an option requiring a supermajority of N:1 is approved by
	    fewer than N times the number of votes it is disapproved by, it
	    is dropped.

	    If an option is approved by no more than the number of votes
	    it is disapproved by, it is dropped.

	    If the only remaining option is the default option, it wins.

	    Otherwise, the default option is dropped.

	(2) The Cloneproof Schwartz Sequential Dropping method is applied to
	    the remaining options. In the event of a tie, the elector with a
	    casting vote decides amongst the tied options.

> What do you think?

I think the above is a counterexample to your idea: it obviously has the
good properties of CpSSD that we want: we're using it and nothing else
to choose between all the real options -- we don't have any fake options,
we don't have any scaling, we don't have any special rules hacked in.

Again, the default option is fundamentally special. It's not there
because people want it to win -- if they want the status quo they need
to specifically nominate that -- it's there to handle our additional
requirements that Condorcet systems don't manage.


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

 ``If you don't do it now, you'll be one year older when you do.''

Attachment: pgpyeEod6fslo.pgp
Description: PGP signature

Reply to: