[maemo-community] Election process referendum

[From: Benson Mitchell]

On Fri, Jan 23, 2009 at 2:29 PM, 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.
>
> Agreed. I'm posting a version of this message to ITT[1] to highlight
> what my conclusions are and pushing this forward to the referendum;
> and that further discussion should be held here.
>
> > I would really like us to use single transferrable vote, which is easy to
> > understand as a voter, and easy to understand when checking the results.
>
> Again, agreed. Despite some voices calling for "range voting"[2], some
> calm heads are calling for a voting mechanism which meets three
> critieria:
>
>  1) Make it easy for people to vote
>  2) Make the results of the election easily verifiable (ideally for
>     a voter)
>  3) Ensure the result well reflects the will of the electorate.
>
> RRV may well be optimal for the third, but the (relatively) complex
> maths makes it fail on the first two.
>

First, though I'm apparently a "voice" rather than a "calm head", I agree on
those three primary goals.

However, I consider range voting to be somewhat better than STV, which also
passes, on the first, and find both STV and RRV somewhat inferior to
plurality, but acceptable, on the second. Finally, I think RRV blows STV
away on the third. I'll go through these one at a time.

1) Ease of voting: This depends on two aspects: the ballot system (which
determines ease of voting proper) and counting system (which determines ease
of determining how to vote, given desired outcomes).

The preferential ballot, as proposed for IRV (but also used with other
preferential counting systems), is fairly simple to use. The voter simply
assigns numbers to candidates, with restrictions that those numbers must be
start from one and occur uniquely and without gaps till the voter stops
voting.

The range ballot is even simpler. The voter again assigns numbers to
candidates, but now without any restrictions. Because of the restrictions on
a preferential ballot, a traditional punched-paper (or equivalent) ballot
suffers from spoilage -- voters inadvertently mark a ballot in violation of
the rules (skipping or duplicating a number), and the ballot must be
discarded. While I presume in the online voting system we use, these errors
would be prevented from occurring, the prevention adds complexity; 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? Either choice is fine,
but either one will cause some confusion for a few voters who expected the
opposite behavior. (It's very unlikely that ballots are actually voted wrong
because of this, but it does mean the system is less easy.)

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.

With RRV, however, honest voting is a reasonable strategy (always better for
your top candidate than not voting), and the best voting strategies proposed
are essentially exaggerations of the exact degree of preference, while
keeping all candidates in the same order. So voters don't need to vote
strategically to avoid hurting their candidates, and don't need such
accurate guesses of the outcome if they do.


2) Ease of verification: This depends directly on the counting method.

For RRV, verification is straightforward with a computer, but does involves
fractional numbers, making hand verification even more tedious and
error-prone than it otherwise would be. I don't see this as a great
disadvantage, given that anyone participating in the election or involved
with Maemo must have some level of computer access. Moreover, as RRV is very
simple mathematically, they can easily perform the verification on a
completely original codebase, rather than depending on libraries.

(While writing this email, I decided to whip up some code to prove this; I
coded the counting algorithm in C in 42 minutes, included some light
testing. The counting algorithm is <60 LoC with K&R bracketing and comments,
and I believe it would be rather short of 30 lines in a suitable high-level
language such as Octave/MATLAB. No special handling for ties is done, but
that would not be necessary to verify results post-election unless a tie had
actually occurred.)

STV, unfortunately, is not a single counting method, but a family of
methods, because there are various ways to determine which af a candidates
votes are surplus and should be transferred. Perhaps the most obvious fair
method is to draw them at random, and indeed some such methods exist;
however, this makes verification impossible. Without knowing which method is
actually applied, it's difficult to compare, but generally verification
difficulty is at least on par with RRV, and complexity increases with the
more accurate systems. Some STV methods also deal in fractional weightings,
requiring a computer.

Both of these, and any other systems based on a preferential or range
ballot, have to condense substantially more ballot information into the same
results as plurality, so there's going to be a cost in complexity of
verification; I don't see RRV as imposing a substantial increase beyond
that.


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 <http://rangevoting.org/BayRegDum.html>.
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.


Finally, RRV has a very nice characteristic, although it's probably of
limited importance here, that it proceeds one round at a time, with
dependence on the set of winners to date, but no dependence on the total
number of seats. This makes some operations simpler. For example, if an
additional seat were to be created, it could be filled without a special
election; calculation with existing ballots can be continued to obtain the
next winner. With STV, it's possible for a recount with more seats to
replace existing winners, but an additional round of RRV will simply add one
more to the set, giving the exact same results as rerunning the election.
(Obviously, when a vacancy arises through disqualification/death/resignation
of a winner, a complete recount may give different results for any winners
seated after them, as the votes that initially went for that candidate were
reweighted according to the "win", but a single round with an updated set of
winners (and new weights) will still select the best replacement, with a
good likelihood of preserving proportionality.)

This kind of robustness is not as critical to a community organization as to
a government, and AFAICT we currently have no rules for vacancies; it looks
like if a council member vacates their seat, the council will operate with 4
members until the next election, so this doesn't matter to us.

> Does anyone have a suggestion for language that should be used in a
> > referendum? Can we work this out & announce it ASAP, please?
>
> So, for the referendum, I'm imagining there being the following
> options (language and wording TBD):
>
>  * No change. The current process[4] is fine.
>
>  * A single transferrable vote. Bullets 4 and 5 ("Each community member
>    gets one vote" and "The 5 nominees with the most votes are elected.")
>    will be changed to XXX (TBD, something like "Each community member
>    ranks ranks one or more candidates in order of preference" and
>    "Council members will be selected according to this single-
>    transferrable vote system[5]:
>
> http://en.wikipedia.org/w/index.php?oldid=265503753#Counting_the_votes
>

As touched on above, there are a number of STV methods depending on how
surplus votes are reallocated.  If consensus is with STV, I think we'll
still need to specify which counting method to use.


>  * None of these options is acceptable.
>
> The Council would decide what to do in the event of the third option
> getting a majority of votes.
>
> Cheers,
>
> Andrew
>
> [1] http://www.internettablettalk.com/forums/showthread.php?p=239466
> [2] http://tinyurl.com/council-vote-rrv
> [3] http://tinyurl.com/council-vote-stv
> [4] http://wiki.maemo.org/Task:Community_Council#Elections
> [5] http://en.wikipedia.org/w/index.php?oldid=265503753#Counting_the_votes
>
> --
> Andrew Flegg -- mailto:andrew at bleb.org  |  http://www.bleb.org/
> Maemo Community Council member
> _______________________________________________
> maemo-community mailing list
> maemo-community at maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-community
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maemo.org/pipermail/maemo-community/attachments/20090127/85b9063b/attachment.htm