[maemo-community] Election process referendum

[From: Benson Mitchell]

On Tue, Jan 27, 2009 at 8:19 AM, Andrew Flegg <andrew at bleb.org> wrote:

> On Tue, Jan 27, 2009 at 11:28 AM, Benson Mitchell
> <benson.mitchell at gmail.com> wrote:
>
>
> [range vs. preferential ballots]
> > if, e.g, a voter has already ranked candidate A as 3rd, and then ranks
> > candidate B as 3rd, is candidate A devoted, or pushed down to 4th?
>
> This should be a validation error in the web front end, and the user
> has to correct it. Presumably the same would apply to any range voting
> where the number entered was outside the range (i.e -10 or 1000), or
> any of these methods which are more complex than "just select your
> most preferred candidate" which have direct number input.
>

Well, actually I was assuming a range  ballot for online voting would use
radio buttons or a slider control, which inherently limit possible inputs to
valid inputs. OTOH, I was assuming radio buttons for ranking, which don't
constrain input to validity. One possible input scheme for an
auto-validating preferential ballot is dual-list-boxes with >> and <<
buttons to add/remove  candidates, and vertically exchanging them in the
ballot side. I hadn't really considered how UI-dependent that criticism
is...

>
> > The counting method, and its implications on voter strategy, however,
> gives
> > RRV a more significant edge. With STV, many situations arise where voting
> > for your favored candidate may hurt his chances of election (versus
> voting
> > against him or not voting at all);  the honest strategy can be seriously
> > counterproductive. The voter _must_ try to predict the outcome to know if
> > one of these situations is occurring, and alter their vote for maximum
> > strategic effect. If they misjudge or disregard this, their honest
> > participation may worsen the outcome.
>
> I've heard this asserted, and seen pages on scorevoting.net which try
> to prove it, but a quick analysis doesn't have me convinced.
>
> Can you explain how this "hurt your preferred candidate(s)" situation
> occurs?
>
> Essentially, it comes down to the fact that candidates are eliminated from
the bottom by a criterion unrelated to their actual success; winners are
determined by accumulating first-choice and transfered votes to reach a
quota, but losers can be eliminated simply from not having enough votes in
the _current_ round, regardless of whether they could still receive enough
transferred votes to reach the quota. Since candidates are only eliminated
when no candidate meets the quota, this effect is prevalent as the ratio of
candidates to seats increases (resulting in more dilution of votes). The
pages on scorevoting.net, of course, are principally about the single-seat
cases of STV (IRV) and of RRV (RV), which make for the simplest such cases,
but the same principles apply with multi-seat versions and proportionately
more candidates.


It's trivial to concoct a ballot where a certain candidate (call him A) gets
the fewest 1st-choice votes, but is everyone else's second pick, and the
first round is closely matched between the other candidates -- if nobody
makes the quota, A, who quite likely should be elected to one of the slots,
will be eliminated in the first round.

It's a little trickier to see the exact circumstances required for a
participation failure, but essentially if some other candidate (say, B)  had
a razor's edge quota, and then you add a handful of A supporters. Now B has
the same number of votes, but the quota is larger, and he no longer makes
it; now A is eliminated, and the A-supporter's votes transfer to their
second choices. If those candidates had stayed home, however, A could have
picked up enough second-choice votes to win a seat.

Some nice pictures for these concepts are
here<http://www.rangevoting.org/IrvExtreme.html>;
the Yee diagrams show the resulting winners for a population randomly
distributed about any point in a 2-d candidate space, and you can see a lot
of places where the wrong candidate flatout wins (because the "right"
candidate got eliminated), and even more where the actual winner is highly
sensitive to voting noise. (Those pictures are from computer simulations
with 5000 voters, and we didn't even have 1000 last election, so we would
expect potentially worse results.)

>
> <snip>
>


> > 3) Accuracy/optimality of results. (As I haven't heard any disagreement
> on
> > this point, I won't spend much time here.)
> >
> > Range voting is, in my view, unambiguously superior in the single-winner
> > case, both logically and empirically. While there's currently no accepted
> > performance metric analogous to Bayesian regret for multi-winner
> elections,
> > it stands to reason that as the logical multi-winner extension of range
> > voting, RRV should be one of the best options available.
>
> The maths behind Bayesian regret seems spot on. I'm not convinced that
> it accurately models how people *feel*. An election method needs to be
> more than just a mathematical model which is provably optimal.
>
Certainly, and there's two lines of attack to show that the model is
unsuited to reality:

First (the one you seem to be thinking), is that the model depends on
modeled voter behavior that does not correspond to actual voter behavior.
Essentially, though, the model assumes nothing about how people's utility
scales work, or whether they make sense; it only assumes that they will vote
in rational accordance with their utility, i.e., with how they feel. So the
place this would break down, if it were to, is not with people irrationally
assigning values to outcomes (that's handled fine), but if they prefer a
certain outcome and irrationally vote against it. _If_ that sort of
irrationality holds true in enough cases to matter, it does invalidate the
Bayesian regret numbers, but it also renders *any* voting system
ineffective.


 The second, and IMO more interesting, line of attack lies on the notion
that you can model the general utility as the uniformly weighted average
utility of voters. This is not generally expressed directly in isolation,
and it took me a while to pinpoint it, but Bayesian regret is predicated on
this egalitarian axiom. (In political elections, there are almost no
plausible exceptions; the obvious ones of race, gender, etc. are generally
out of consideration. In a software community, however, it's conceivable
some would argue, e.g., that developers' utility should be weighted heavier
than end-users, or that content-creators should outweigh both.) However,
range voting is robust against this argument as well, simply because no
obvious election method will favor any particular class drawn along those
lines; the only obvious ways to achieve such results is controlling
suffrage, not voting methods, and once the weighting (supposting it were
desired) was established through controlled suffrage, Bayesian regret
analysis could be validly applied to the remaining voters. While I find this
whole line of reasoning quite interesting. it really has no direct
application here, as suffrage is already fixed, and I don't really see a
genuinely desirable bias anyway.


On Sat, Jan 24, 2009 at 8:36 AM, Andrew Flegg <andrew at bleb.org> wrote:

> On Fri, Jan 23, 2009 at 2:40 PM, Dave Neary <dneary at maemo.org> wrote:
> >
> > We can run a referendum election for changes to theh voting procedure
> > pretty quickly, and as was pointed out already, we should probably get a
> > move-on.
>
> Assuming the three options I outlined ("No change", "STV" and
> "Neither") have consensus, or aren't argued with, by Sunday, 1st
> February 2009 then we
>                                     ^^^^^^^^^^^^^^^^^^^^^^^^^
> enact the referendum to start then and run for 1 month. This gives us
> over a week for debate.
>
Apologies to all for being so late with this reply; we are getting close to
the proposed time. I'll try to stay a *little* more on top of discussion
these next few days. :-)

So far, I think Dave, Andrew, and I have spoken out on this... anyone else
have opinions? (I'm gonna go bump the itT thread as well...)


Benson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maemo.org/pipermail/maemo-community/attachments/20090131/8e2cbf61/attachment.htm