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 requirement. 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. Cheers, aj -- 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