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