On Sat, June 10, 2000 10:00 PM, Branden Robinson wrote: > >On Sat, Jun 10, 2000 at 09:53:40PM -0500, Chris Lawrence wrote: >> Now follows a dissertation on the voting system: >[...] > >Thanks for the primer; this was quite possibly the most useful message in >this entire thread. >
Except that Chris Lawrence is mistaken as to how Condorcet's method is implemented within the Debian Project. Yesterday he wrote: >A primer on Concordet: you should rank all options unless there is an >option you honestly don't care about. Not voting for an option IS NOT >THE SAME as ranking it lower than another option. For example, if you >like John's proposal on the second ballot shown above, and vote 1--- >(- = no vote), you haven't really voted, because you haven't expressed >any relative preferences. [...] While it is possible to interpret a ranked ballot in the way Chris Lawrence suggested, the more usual practice is to consider all unranked options the same as if they had been ranked EQUALLY LAST (as an aside, I am a participant in something called the 'Election Methods (EM) List, where there has been active discussion of Condorcet and other single-winner methods for a number of years, and this is the usual assumption -- see http://www.eskimo.com/~robla/politics/condorcet.html for more information). So for Chris' example above, the ballot '1---' is treated exactly the same as if the ballot had been marked '1444', thus scoring a total of 3 votes (rather than 0), with the 1st option scoring 1 vote against the 2nd, 3rd, and 4th options, respectively. This is done in order to avoid the problem he identified, for those who neglect to rank all the options explicitly. It is easy to verify that the Debian Project's implementation of Condorcet's method (for some reason called the 'Concorde' method in the Constitution (?)) works this way, since complete sets of ballots and outcomes are provided for certain elections. Consider the following results from Vote #2: Vote 0002 Outcome logo1 results - 107 valid votes SINGLE License has: 35 1st preference votes 44 2nd preference votes 9 3rd preference votes 19 no preference votes DUEL Licnese has: 68 1st preference votes 18 2nd preference votes 6 3rd preference votes 15 no preference votes FURTHER Discussion has: 4 1st preference votes 29 2nd preference votes 42 3rd preference votes 32 no preference votes SINGLE License Dominates FURTHER Discussion [77 - 20] DUEL Licnese Dominates SINGLE License [69 - 37] Dominates FURTHER Discussion [85 - 17] FURTHER Discussion ***** If you tally the number of votes a particular option received against all the alternatives, it should be equal to 2*1st-preference votes + 1*2nd preference votes (in this 3-way race), since a 1st preference will score 1 vote against the remaining two choices, and the 2nd preference will score a vote against the last choice. Verifying this with DUEL License, for example, we get: 69+85 = 154 votes 68*2+18 = 154 votes -- check. If Chris' interpretation of the ballots had been correct, this would not be true, since some voters only ranked a single candidate, and their ballots would not have counted *at all*. Looking at the ballots themselves, we see: FURTHER Discussion -----+ DUEL Licnese ----+| SINGLE License ---+|| ||| [...] [EMAIL PROTECTED] Adam Di Carlo -1- [...] [EMAIL PROTECTED] Branden Robinson --1 [...] Had Adam Di Carlo's ballot not been counted, the tally of votes against his two unranked candidates would not have included votes from his ballot, in which case the pairwise vote totals would have been 68+84 = 152 votes or less (depending on how many other voters did this). Therefore, Debian's voters DO NOT have to be overly concerned about the effects of partial ranking -- the system is designed to take into account the fact that they may do this, and makes a reasonable assumption about what was intended by considering the unranked options as having been ranked equally last. Having said that, it is *still* a good idea for voters to explicitly rank all the options, if they have any preference *at all* between the available choices. Doing so will maximise the impact that the voter's ballot will have on the outcome. Partial rankings, or many equally-ranked alternatives on the ballot reduces the number of pairwise decisions the voter is participating in, and thereby lessens the chance that their ballot will be the deciding factor in the election outcome. It might be a good idea for the Debian project to amend the Constitution so that this little detail is made explicit. Whereas the current definition of the method merely states: A.6. Concorde Vote Counting This is used to determine the winner amongst a list of options. Each ballot paper gives a ranking of the voter's preferred options. (The ranking need not be complete.) This should probably be changed to something like: A.6. CONDORCET Vote Counting This is used to determine the winner amongst a list of options. Each ballot paper gives a ranking of the voter's preferred options. (The ranking need not be complete; UNRANKED OPTIONS WILL BE TREATED AS THOUGH THEY HAD BEEN RANKED EQUALLY LAST.) The tiebreaker specified in A.6.5 also needs some work, but I won't go into that now :-) I am not a Debian developer (merely a satisfied user), but would be pleased to assist with drafting an amendment that would address the minor problem identified above and clarify the use of the tiebreaker, etc. if anyone considers it worth the effort. In any case, the Debian Project is to be commended for having chosen such an excellent system for making group decisions. For those of us on the EM list (http://www.eskimo.com/~robla/em/) who study these things, Condorcet's method is widely regarded as the best single-winner method available. We are very pleased that there is at least one organisation in the real world that's putting it to good use. Cheers, Norman Petry
