[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying

Raul Miller wrote:
> On Tue, May 20, 2003 at 12:19:33PM -0700, John H. Robinson, IV wrote:
> >    The amendment uses the concept of a Quorum requirement to inhibit
> >    "stealth decisions" by only a handful of developers. While this is a
> >    good thing, the per-option quorum from the amendment has a tendency to
> >    further influence the outcome of the vote in a hard-to-understand
> >    way. This modification corrects this deficiency.
> "Hard to understand"?  We'd require a certain level of voter approval
> before we'll consider an option -- options which don't achieve that
> can't win.  How is this "hard to understand"?

by counting a ranking higher than default as a special vote. this is
what makes it hard to understand. it also opens up the avenue for
strategic voting via insincere voting.

example: quorum of 20, two ballots on the measure, plus the default
option. two major schools of thought: those that support option A, and
those that support option B. privately, each consider action on the item
better than no action, but the A supporters, being the smaller of the
two camps (10 members, vs the 15 members for B), really want their
measure to win. they, as a block, vote 132. the B supporters vote
sincerely, and vote 213.

using the rules as proposed by Manoj, option B would fail to make its
better-than-default quota (having only 15 of 20). option B would then be
dropped. A easily beats default, and thus A wins.

using a straight Condorcet, or even a Cloneproof SSD, option B would
win. my amendment restores that feature of Condorcet/Cloneproof SSD.

> Note also that your amendment would create situations in which a
> developer voting against an option might cause that option to win*.
> How is this "easier to understand"?
> * For example:
>    quorum: 20
>    developer has reason to believe that not many votes will be cast.
>    developer has reason to believe that the few votes which will be
>    cast will be in favor of an option which developer is opposed to.
>    Casting ballot against that option might cause ballot to achieve
>    quorum.

this is a strawman, because if <R people vote, then no option will
achieve the R+1>default per-item quota.

>    [Yes, this circumstance is unlikely -- that's because "not meeting
>    quorum" is itself unlikely.  If "not meeting quorum" becomes 
>    likely then this example also becomes likely.]

even if this were the case, if there were no quota requirements, as in a
straight Condorcet or Cloneproof SSD, the most preferred option would win

the purpose of quorum is to inhibit ``stealth decisions'' by only a few
developers. this purpose is met very well by the amended implementation
of quorum. quorum is not meant to change the winner of the vote.

> To make your proposal work right, we'd need a separate quorum
> determination phase which is independent of the voting phase.

i fail to see that argument.


Reply to: