-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
[Please follow up to [EMAIL PROTECTED]
In December 2000, Raul Miller proposed a GR to fix the voting
process as defined in the constitution. The GR was withdrawn until a
committee assigned to study the problem returned with a
recommendation. We have a clear recommendation for the voting method
(Clone proof SSD); and a less clear one with how to deal with super
majority issues.
I posted this on debian-vote last week, and there has been a
clarifying note by aj, which is included below, and mostly positive
responses, so I am taking this to the next phase. Raul, if you want
to re-propose your GR, please feel free to do so.
We now need to create the formal language that would replace
the current wording of the constitution, as the net step.
======================================================================
First, the full Monte:
The emails that started this:
http://lists.debian.org/debian-vote/2000/debian-vote-200002/msg00014.html
http://lists.debian.org/debian-vote/2000/debian-vote-200002/msg00015.html
http://lists.debian.org/debian-vote/2000/debian-vote-200002/msg00016.html
http://lists.debian.org/debian-vote/2000/debian-vote-200002/msg00017.html
http://lists.debian.org/debian-vote/2000/debian-vote-200002/msg00025.html
http://lists.debian.org/debian-vote/2000/debian-vote-200006/msg00055.html
http://lists.debian.org/debian-vote/2000/debian-vote-200006/msg00077.html
http://lists.debian.org/debian-vote/2000/debian-vote-200006/msg00054.html
http://lists.debian.org/debian-vote/2000/debian-vote-200006/msg00095.html
http://lists.debian.org/debian-vote/2000/debian-vote-200006/msg00117.html
http://lists.debian.org/debian-vote/2000/debian-vote-200006/msg00118.html
And search for Condorcet in debian-vote archives for Oct-Dec
2000 fofor the GR.
The joint Debian-em committee was set up in these emails:
http://lists.debian.org/debian-vote/2000/debian-vote-200012/msg00091.html
http://lists.debian.org/debian-vote/2000/debian-vote-200012/msg00092.html
http://lists.debian.org/debian-vote/2000/debian-vote-200012/msg00093.html
http://lists.debian.org/debian-vote/2000/debian-vote-200012/msg00094.html
http://lists.debian.org/debian-vote/2000/debian-vote-200012/msg00115.html
The recommendations of the committee, and discussions thereof,
are here:
http://people.debian.org/%7Esrivasta/voting-recommendation.txt
======================================================================
To recap the discussions held nearly a year and a half ago
(examining the debian-vote and debian-devel archives may prove
illuminating).
======================================================================
From: MIKE OSSIPOFF <[EMAIL PROTECTED]>
If the Debian rules are strictly followed, then, by rule 3,
all options that are dominated [pairwise beaten] by at least one
other option are discarded, and references to them in the ballot
papers will be ignored.
That means that unless there's an "undominated" alternative
("option"), every alternative will be discarded and deleted
from the ballots.
Rule 4 provides for electing the alternative that dominates
all others, if there is one, and rule 5 says what to do if there
is more than 1 option remaining--but there will never be more
than zero options remaining unless there'd been a BeatsAll winner,
a candidate who "dominates" every other candidate.
With pairwise voting, it makes all the difference how circular
ties are dealt with. When Instant Runoff (they call it 1-winner
STV) is used to solve circular ties, that means that the group
of voters who are in a position to make a circular tie, by
order-reversal, or by truncation, sincere or strategic,
are also the group that has an automatic win if they do make
a circular tie and the middle candidate gets eliminated.
Example:
40: A (the A voters truncate)
25: B (2nd choices of B voters aren't listed, since they're likely
to be divided both ways, and we don't know which side would
get more from them)
35: CB
***
The A truncation makes a circular tie, though B is the Condorcet
winner. In the resulting IRV count, B gets eliminated, and A
wins.
With the currently-specified rule for solving circular ties in Debian
elections, it's no coincidence that the A voters are in a position to
make a circular tie, by truncation, and are also the winners when that
tie is solved by the Alternative Vote, after B is eliminated.
The reason why the A voters are in a position to make a circular
tie is because A beats C pairwise. Otherwise, the truncation
would merely give the election to C. And the reason why A wins
after B is eliminated is also because A beats B pairwise.
So then, the people who are in a position to make a circular tie
are set up to win it too, when the circular tie is solved by
the Alternative Vote, as the rules currently specify.
The A voters can gain by truncation (as they do in the example),
and can't worsen their outcome by it. If they're sure that A
beats C pairwise, then the strategy of truncating dominates the
strategy of voting a complete ranking. So that circular tie
solution makes offensive truncation those voters' best strategy.
And it creates a defensive strategy problem for that majority
who prefer B to A. If it's widely expected that A will beat C
pairwise, so that truncation is clearly the best strategy for the
A voters, then the C voters need to rank B equal to C, to foil
the A voters' attempt to create a circular tie. But if the A voters
escalated their offensive strategy to order-reversal, ranking
C over B, then the C voters would need to vote B over their
favorite in order to prevent the A strategy from working.
B is the candidate who'd beat each one of the others pairwise if
everyone sincerely ranked all the candidates. Such a candidate
is called the "Condorcet winner".
======================================================================
From: "Norman Petry" <[EMAIL PROTECTED]>
The main problem with Debian's current rules are that they are indecisive
when confronted with a circular tie; there is also the minor problem I
mentioned earlier about unstated assumptions in the interpretation of
truncated ballots. Since the problem of indecisive rules cannot be solved
without amending the Constitution, it makes sense to carefully choose one of
the better methods of resolving ties. A wide range of tiebreakers are
available to solve this problem, but they vary significantly in quality and
it is difficult to make good choices from among the available options
without thorough study. Members of the Election Methods list (Mike
Ossipoff, myself and others) have studied this problem extensively, and we
would be pleased to provide you with a specific recommendation as to how the
problem would be best solved. As well, Rob Lanphier (a software developer
who operates the EM list) and I have both developed GPLed implementations of
our preferred methods in both Perl and Python that could probably be adapted
to your existing system of vote-counting, if a constitutional amendment is
approved.
======================================================================
The Condorcet method specified in the Constitution is clear
about such things in the case of a GR, where only a majority is
required. How does it work when two of the ballot options require a
supermajority to pass?
There are at least two issues which could use correcting:
* the method for resolving circular ties
* how to make alternative resolutions available
======================================================================
From: MIKE OSSIPOFF <[EMAIL PROTECTED]>
The constitution revision committee arrived at a concrete recommendation
for the count rule, for counting the rankings and choosing a winner:
We voted to recommend Cloneproof SSD. It's equivalent to another
procedure that is known sometimes as BeatpathWinner and sometimes
as Schulze's method. But we choose Cloneproof SSD as the procedure
to recommend, the rank-count rule to recommend.
======================================================================
From: Norman Petry <[EMAIL PROTECTED]>
If you read through the discussion, you'll note that our committee
actually *did* make a preliminary decision about the supermajority
procedure we preferred, but we also decided to defer the final
decision until certain other matters had been discussed. Although we
then resumed discussion of the supermajority issue, I don't think we
reached any final decision.
Our preliminary decision was to recommend what we called 'Miller-1',
which is a very simple and effective method of handling multiple
proposals that have different supermajority requirements: the procedure
is to simply consider whether each proposal has met its supermajority
requirement when compared to the status-quo, and eliminate any
alternatives that do not meet their supermajority threshold. Any
proposals which survive this elimination are compared directly using the
regular count procedure (that is, a simple majority chooses between two
proposals if both are eligible, even if one is an ordinary GR (1:1) and
the other is a constitutional amendment (3:1?), as long as the
constitutional amendment achieves the necessary 3:1 supermajority
against the status quo). I still think this is probably the best
approach to handling supermajorities within the Debian constitution.
======================================================================
Finally, A precis from Anthony Towns:
* The vote counting method is really "Condorcet" not
"Concorde". Kinda, almost.
* It's not obvious how to count votes under the current
constitution. eg, the 2001 DPL election considered 123-- to
prefer candidate A over candidates B and C, and candidate B over
candidate C, but to express no opinion at all on candidates D or
E -- even in comparison to A, B or C. This resulted in people
voting, eg -1---, and not having their vote mean anything at
all. Whether or not it's possible to vote 21234, if you've
got equally ranked second choice candidates isn't clear either.
* The description of the way votes are counted in some corner
cases seems buggy. In particular, if A.6(4) doesn't apply, then
A.6(3) will usually have discarded *all* options. Other counting
methods which the voting-geeks quoted in Manoj's message like
cope substantially better in these cases. Additionally, in
most of these cases, a *single* vote added/removed won't make a
difference, so the "casting vote" would have to be equivalent
to possibly many "normal votes", which is odd. That's not
to say the system we have doesn't work, but there are other
systems that work better, and make more sense.
* The description of supermajority handling doesn't make it clear
whether two separate votes are required, or if just one is
permissable. Having two separate votes is unnecessarily tedious
and complicated and (for supermajority results especially), can
result in "deadlocks" -- if the first vote chooses A, and the
second vote says "No" to A, there's no obvious thing we can do.
OTOH, if you're having just one vote, A.6(7) doesn't make much
sense if there's a supermajority option and a regular option
on the ballot -- it seems like it requires the supermajority
to be preferred 3:1 against _every_ other possibility, which
probably isn't desirable.
OTOH, so far none of this has mattered: however you counted the votes
in the 2001 elections you got the same result, none of the corner
cases have come up, we haven't actually had any supermajority votes,
and there are definitely more important things for us to be doing than
worrying about "typos" in our voting system's name. The electoral guys
have some somewhat dubious estimates of how likely we're to end up with
any of the corner cases, somewhere back in the archives, fwiw.
======================================================================
I also want to add that doing the right thing, even when the
bad things only occur in low probability corner cases, has been a
hall mark of Debian, and, secondly, we have had two other GR's
waiting on the resolution of how we handle a single vote with where
one of the options, but not all of them, require super majority to
pass.
manoj
- --
Real Men don't make backups. They upload it via ftp and let the
world mirror it. Linus Torvalds
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Processed by: Debian GNU/Linux -> Emacs -> Gnus -> Mailcrypt
iD8DBQE9bTkdIbrau78kQkwRAp6zAJ90P5unKuNDK536bz85AuFL4LzAFgCdFLKX
z2PuCGdtNdmOGLnxr/9eVc8=
=FmWQ
-----END PGP SIGNATURE-----
