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
regardless.
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.
-john
Reply to: