Re: Per-item "quorum" and truncated ballots
On Fri, May 23, 2003 at 05:24:59PM -0400, Buddha Buck wrote:
Imagine a vote along the lines of:
100 ballots of the form:
 Red, [ ] Blue, [ ] Default
100 ballots of the form:
 Red, [ ] Blue,  Default
25 ballots of the form:
[ ] Red,  Blue, [ ] Default
with an R of 105.
I presume you mean with a quorum of 105. Which would mean that we have
something like 44100 debian developers.
The defeats matrix looks like
Red Blue Default
Red --- 200 100
Blue 25 --- 25
Def 0 100 ---
In this example, Red is the IDW, and absolutely no one thought that Red
was worse than the default option. Yet Red is rejected because fewer
than 105 people thought it was better than the default option, so
Is this the "expected" behavor?
Out of more than fourty thousand debian developers, less than one hundred
stated that they preferred red over the vote defaulting?
Yes, I'd say that this is the expected behavior. Those other votes,
which rank red and default equally above blue, constitute votes against
blue, not votes for red. Those people would have accepted red as being
no worse than the current situation, but they didn't actively think it
was a good idea.
So you are saying it is acceptable and desirable for there to be no way
to express truely equal preference for "Further Discussion" and some
other option? Using my example, voting red equal to blue doesn't hurt
or hinder either options chances of winning in relation to each other.
But voting red equal to the default hinders red's ability to get
accepted in favor of defaulting.
We've made three changes to SSD:
1) We've instituted a per-option quorum, requiring a minimum number of
for a particular option over the default in order to be considered.
2) We've instituted the ability to rank options as equal on a ballot.
3) We are using the ranking relative to the default option as proxy
for an approval ballot, and only considering options that are approved
by the majority.
Our analysis of 1 and 3 have been based on the law of the exclused middle:
for any ballot, either A>D or D>A. We haven't considered the effects of 2.
I think that the combination of all three changes has unforseen effects.
In particular, I think change #2 sets up the expectation with developers
that they can vote "I don't care which of these two options win", while
the other two changes do not treat a ballot equating an option and the
default as neutral with regard to that option and the default -- they
favor the default.
I think change #1 is the most troubling for me, and I would not mind
seeing its removal. It's designed to eliminate options that don't have
many supporters. But surely if there are enough ballots cast, an option
that doesn't have many supporters will be unlikely to win anyway. The
only time an option that doesn't have many (active) supporters has a
chance of winning is when it also doesn't have many (active) detractors
-- and when everyone else is expressing no preference one way or the other.
Why shouldn't the will of a small number of supporters win out over the
will of a smaller number of detractors when the majority opinion is "I