Re: RFD: amendment of Debian Social Contract
Branden Robinson wrote:
On Sat, Nov 08, 2003 at 08:28:54PM -0500, Raul Miller wrote:
On Sat, Nov 08, 2003 at 06:56:15PM -0500, Branden Robinson wrote:
Anthony's example splits a potential "change social contract"
supermajority into two, and yours splits it into three.
This pretty much ensures the defeat of any option that requires a
3:1 majority, and makes it extremely difficult even to satisfy a
propostion that requires only a simple majority.
This doesn't make sense.
Of course it does. Consider:
[ ] Choice 1: Remove Clause 5 of the Social Contract(, Keep Debian
Swirl Red) [ ] Choice 2: Remove Clause 5 of the Social Contract,
Make Debian Swirl Green [ ] Choice 3: Remove Clause 5 of the Social
Contract, Make Debian Swirl Blue [ ] Choice 4: Further Discussion
250 ballots ranking 1234 250 ballots ranking 2314 250 ballots ranking
3124 250 ballots ranking 2221
Choices 1, 2, and 3 require a 3:1 majority to pass, of course.
What happens? Our voting system does not give us the ability to
reach the common-sense conclusion that 3 out of every 4 voters wanted
to remove clause 5 from the Social Contract. Instead, "further
discussion" wins. Is that because the proposition to remove clause 5
from the Social Contract failed to persuade 3 out of 4 developers
that it was a good idea? That doesn't follow from interpretation of
the results.
It follows from a correct interpretation of how the consititution
results. The voting system is designed to be cloneproof, so that the
vote-splitting strategy doesn't work.
"3:1 Majority", in this case, is defined in relation to the "default
option", which is Choice 4. To test the supermajority requirement,
choices 1, 2 and 3 are not compared with each other. Check section
A.6.3 of the Debian Constitution (available at
<http://www.debian.org/devel/constitution>)
I assume, from your further comments, that you think this vote should
mean that a supermajority of the voters support removing Clause 5, and
the addition of choices 2 and 3 spoilt the result. This example is
flawed, in that even without choices 2 and 3, further discussion would
have won, since the Constitution says that the votes in favor of option
1 over option 4 must be "strictly greater" than three times the votes in
favor of option 4 over option 1 (section A.6.3.2). Since 750 people
preferred option 1 over option 4, and 250 preferred option 4 over option
1, the ratio of those two votes is exactly 3, not strictly greater than
3. Option 1 would fail.
I think your thesis was not intending to be dependent on such
edge-cases, but rather merely on the thesis that irrelevant options
"split the vote", as it were, and dilute the supermajority. So I'm
going to assume, for the sake of argument, six additional voters, three
of whom voted 2314, two voting 1234 and one more voting 3124:
252 ballots ranking 1234
253 ballots ranking 2314
251 ballots ranking 3124
250 ballots ranking 2221
And I'm going to walk this through the entire voting counting procedure,
step by step:
# A.6.1 Each voter's ballot ranks the options being voted on. Not all
# options need be ranked. Ranked options are considered preferred
# to all unranked options. Voters may rank options equally.
# Unranked options are considered to be ranked equally with one
# another. Details of how ballots may be filled out will be
# included in the Call For Votes.
We have the ballots above.
# A.6.2 If the ballot has a quorum requirement R any options other than
# the default option which do not receive at least R votes ranking
# that option above the default option are dropped from
# consideration.
I think it is reasonable to assume that since all three options 1, 2 and
3 received over 500 votes more votes ranking those options above the
default option than ranking the default option over any of those
options, that any sensible quorum requirement has been met.
# A.6.3 Any (non-default) option which does not defeat the default
# option by its required majority ratio is dropped from
# consideration.
#
# 1. Given two options A and B, V(A,B) is the number of voters who
# prefer option A over option B.
# 2. An option A defeats the default option D by a majority ratio N,
# if V(A,D) is strictly greater than N * V(D,A).
# 3. If a supermajority of S:1 is required for A, its majority ratio
# is S; otherwise, its majority ratio is 1.
We have three non-default options to consider here: "R", "G", and "B",
all of which have a supermajority of 3:1, and thus a majority ratio of 3.
We have:
V(R,D) = 756 > 3* V(D,R) = 3 * 250 = 750 so R is not eliminated
V(G,D) = 756 > 3* V(D,G) = 3 * 250 = 750 so G is not eliminated
V(R,D) = 756 > 3* V(D,B) = 3 * 250 = 750 so B is not eliminated
# A.6.4 From the list of undropped options, we generate a list of
# pairwise defeats.
#
# 1. An option A defeats an option B, if V(A,B) is strictly greater
# than V(B,A).
We have the following list of pairwise defeats:
R defeats D by a margin of 756 to 250
G defeats D by a margin of 756 to 250
B defeats D by a margin of 756 to 250
R defeats G by a margin of 505 to 251
G defeats B by a margin of 503 to 253
B defeats R by a margin of 504 to 252
# A.6.5 From the list of [undropped] pairwise defeats, we generate a set
# of transitive defeats.
#
# 1. An option A transitively defeats an option C if A defeats C or
# if there is some other option B where A defeats B AND B
# transitively defeats C.
R transitively defeats D (directly)
R transitively defeats G (directly)
R transitively defeats B (via G)
R transitively defeats R (via G and B)
G transitively defeats D (directly)
G transitively defeats B (directly)
G transitively defeats R (via B)
G transitively defeats G (via B and R)
B transitively defeats D (directly)
B transitively defeats R (directly)
B transitively defeats G (via R)
B transitively defeats B (via R and G)
# A.6.6 We construct the Schwartz set from the set of transitive
# defeats.
#
# 1. An option A is in the Schwartz set if for all options B, either
# A transitively defeats B, or B does not transitively defeat A.
R is in the Schwartz set since it transitively defeats R, G, B, and D
G is in the Schwartz set since it transitively defeats R, G, B, and D
B is in the Schwartz set since it transitively defeats R, G, B, and D
D is not in the Schwartz set since it doesn't transitively defeat R and
R transitively defeats it. (The same relationship between D and either
of B and G also holds. D is defeated by everyone).
Since D defeats no option under consideration, it can't be in the
Schwartz set. I won't list it anymore as an option.
The Schwartz set is {R, G, B}
# A.6.7 If there are defeats between options in the Schwartz set, we
# drop the weakest such defeats from the list of pairwise
# defeats, and return to step 5.
#
# 1. A defeat (A,X) is weaker than a defeat (B,Y) if V(A,X) is less
# than V(B,Y). Also, (A,X) is weaker than (B,Y) if V(A,X) is
# equal to V(B,Y) and V(X,A) is greater than V(Y,B).
# 2. A weakest defeat is a defeat that has no other defeat weaker
# than it. There may be more than one such defeat.
Our defeats among the Schwartz set, copied from above, D eliminated, and
sorted via strength, were:
R defeats G by a margin of 505 to 251
B defeats R by a margin of 504 to 252
G defeats B by a margin of 503 to 253 <--- You are the weakest defeat,
Goodbye
# A.6.5 From the list of [undropped] pairwise defeats, we generate a set
# of transitive defeats.
#
# 1. An option A transitively defeats an option C if A defeats C or
# if there is some other option B where A defeats B AND B
# transitively defeats C.
Looking solely at the list:
R defeats G by a margin of 505 to 251
B defeats R by a margin of 504 to 252
we have:
R transitively defeats G (directly)
B transitively defeats R (directly)
B transitively defeats G (via R)
# A.6.6 We construct the Schwartz set from the set of transitive
# defeats.
#
# 1. An option A is in the Schwartz set if for all options B, either
# A transitively defeats B, or B does not transitively defeat A.
B transitively defeats all other options, so B is in the Schwartz set.
R does not transitively defeat B, yet B transitively defeats R, so R is
not in the Schwartz set.
Similarly, G isn't in the Schwartz set because of it's relation to B.
The Schwartz Set (version 2) is {B}
# A.6.7 If there are defeats between options in the Schwartz set, we
# drop the weakest such defeats from the list of pairwise
# defeats, and return to step 5.
#
# 1. A defeat (A,X) is weaker than a defeat (B,Y) if V(A,X) is less
# than V(B,Y). Also, (A,X) is weaker than (B,Y) if V(A,X) is
# equal to V(B,Y) and V(X,A) is greater than V(Y,B).
# 2. A weakest defeat is a defeat that has no other defeat weaker
# than it. There may be more than one such defeat.
There are not defeats between the options in the Schwartz set, this step
is skipped, and we stop looping.
# A.6.8. If there are no defeats within the Schwartz set, then the
# winner is chosen from the options in the Schwartz set. If
# there is only one such option, it is the winner. If there are
# multiple options, the elector with the casting vote chooses
# which of those options wins.
Since the Schwartz set has only one option (B), it wins. In this case,
that means that Section 5 of the Social Contract is deleted, and the
Debian Logo turns blue.
The thing that defeats an option -- even an option with a
supermajority requirement -- is that not enough voters think it's
good enough.
"Good enough" relative to what? Not relative to some abstract
notion; it has to be good enough *relative to the other options on
the ballot*. If all the options on the ballot are unacceptable, we
can expect a voter to rank "Further Discussion" alone as preference
#1.
"Good enough" relative to the default option, not all other options on
the ballot. See A.6.3.
This has nothing to do with how many options are on the ballot.
It has everything to do with how many options are on the ballot if
irrelevant amendments are proposed.
Can you give a better example? The above one is flawed.
Sarcasm aside, when the committee making the recommendation to go with
Cloneproof SSD as our vote counting method deliberated, we did consider
how vote splitting would affect the vote. We also considered the effect
of clones (options which are sufficiently similar they always get ranked
together on ballots).
What was ultimately recommended was a combination of an "Approval"
variant (options are marked as either "acceptable" or "not acceptable",
and only acceptable options are considered. In our case, voting an
option above the default option marks it as "acceptable") and a
Condorcet variant (we consider the totality of pairwise defeats at once).
Approval, especially as it is applied here as a feeder into another
system, does not compare options to each other, but rather treats each
option as it's own entity. If there is 1 amendment, or 2, or 50,
irrelevant or not, each stands or fails on it's own in the approval
phase. Votes can not really be "split" in this stage.
Condorcet methods likewise tend to be immune to vote splitting because
Condorcet methods (including CSSD) look at a much larger chunk of
available information that other methods (like "first past the post" or
Instant Run Off).
Votes are split when voters prefer options A and B over option C, but
differ over their preference of A over B or B over A, but the counting
method can't make use of all that information. First Past The Post
would count the voter who prefers A over B over C as voting for "A", and
the preference of B over C is lost. IRV would eliminate B, and the
preference of B over C is lost again.
Condorcet methods, on the otherhand, look at the totality of
preferences, and would only eliminate the preference of B over C if
there was a good reason to. In CSSD, it would be implicitly eliminated
if one of B or C was not in the Schwartz set, and thus wouldn't effect
the outcome; or if B over C was a weakest defeat, meaning it didn't have
a lot of support. In the typical vote-splitting schenario where people
complain about it, the B over C preference would be implicitly
eliminated because more people would prefer A over C and B over C, so C
would most likely not be in the Schwartz set.
So, combine the methods, and you get a two-part method, neither of which
is vulnerable to vote-splitting. And CSSD is deliberately designed to
be unaffected by clones.
Of course, if enough people think something else is a better idea,
it will win because not enough people thought the lesser idea was
good enough. But this has nothing to do with supermajority.
Inherently, no, but the flaw I claim to have identified is easier to
exploit in any vote where one of the options requires a
supermajority to pass (such options are the juiciest candidates for
"attack").
What was that flaw again? I don't see it.
Note also that statements which don't make sense pretty much make
useless the concept of referring back to the posts which contain
them.
I'm not sure what you mean by this. Is this an effort to wave aside
basically everything I've said, or are you being more subtle?
You are not being clear. You claim to have an exploit of the voting
method, and are concerned that your proposed proposal will be vulnerable
to people wanting to defeat it via that method of exploit. However, as
far as I can see, your exploit is based on a misunderstanding of how the
voting method deals with the issues you raise.
Reply to: