Re: GNOME Board of Directors Foundation Elections Spring 2009 - Preliminary results

[Dave Neary <dneary gnome org>]

Hi,

A small correction to explain exactly how random transfers work:

Filippo Argiolas wrote:
> - with Random Transfer, 20 ballots are picked randomly (assuming those
> 60 votes are already random you can just pick last 20 received, first
> 20, or more complex randomizing methods). The thing is that this way
> you completely lose the second order preference of the remaining 40
> ballots and assume the 20 ones you randomly picked are a
> representative enough sample.

It's slightly more complicated than this.

With random transfer what you do is this:

Count all of the second preferences corresponding to Vincent's first 
preferences (or, in the case where Behdad is 2nd preference, 3rd 
preferences since Behdad is elected, and thus no longer in the race):

Brian: 13
Diego:  3
German: 7
Hubert: 2
Jorge:  0
Lucas: 26
Og:     3
Srini:  6

Non-transferable: 0 (non-transferable votes are those where no candidate 
with lower preferences is still in the race - someone votes Vincent 1, 
Behdad 2 and no-one else, for example).

Now, you calculate how many of these votes you transfer proportional to 
the size of the stack (we're transfering 33 of 60 votes, multiply by 
33/60 and round up or down to get to 33 votes:

Brian:  +7 (rounded down from 7.15)
Diego:  +2 (rounded up from 1.65)
German: +4 (rounded up from 3.85)
Hubert: +1 (rounded down from 1.1)
Jorge:  +0
Lucas: +14 (rounded down from 14.3)
Og:     +2 (rounded up from 1.65)
Srini:  +3 (rounded down from 3.3)


Now, here's where random transfer comes in.

We will transfer 14 of Lucas's 26 2nd preferences at random. In that 
case, there's no issue, because Lucas get up to 27 votes, is elected and 
has no surplus to redistribute.

Where it becomes an issue is when we transfer 7 of Brian's 13 
preferences, bringing him to 26, and when we redistribute Behdad's 
surplus, we then redistribute 6 of 12 preferences, bringing him to 32 
votes, with a 5 vote surplus to distribute.

That's where it gets hairy, because the distribution of that surplus 
will depend on which ballots got transferred to Brian.

It gets even hairier in the 5th count, which is the elimination of Og. 
At that stage, Og's gotten up to 10 votes after distributing Brian, 
Behdad and Vincent's preferences. Of those 10 votes, 6 come from 
transfers - 2 (of 4 preferences) from Vincent, 3 (of 6 preferences) from 
Behdad, 1 (of 7 preferences) from Brian. So now to see who those votes 
transfer to, there are 6 votes chosen at random from a pool of 17 votes, 
which theoretically will be representative of the people like next best 
after Og, but maybe not so much also.

After that, we have the redistribution of votes for Hub, and again the 
issue presents itself - in the vote I ran, Hub ended up with 14 votes 
after count 5, including 7 first preferences, 1 transfer from Vuntz, 4 
from Behdad, 1 from Brian, 1 from Og - and of the 7 transfers, they've 
been chosen at random from a pool of 2, 7, 5, and 1 respectively.

At which case, we are down to 2 candidates, and the result might depend 
on which ballots were transferred from various candidates beforehand to 
see whether Sri ends up on 18, 19 or 20 votes, and whether Jorge ends up 
on 18 or 19 votes. In all sitautions, the last seat is decided by a 
margin of 1 or 2 votes.

> - with Fractional Transfer you don't transfer a sample but *all* the
> 60 ballots with a fractional weight that makes them sum up to the
> surplus (20 in the example). This way you're caring about all
> preferences of all ballots, giving a clearly fairer representation of
> the electors' desires. The only downside of this method it that it is
> more complex, to apply not to understand (i.e. you cannot count
> ballots by hand), but given that we're already using a software to
> count the ballots I really don't see the point.

Exactly. In this specific case, we don't round the numbers & transfer 
actual ballots, we transfer each preference from Vuntz to Brian (say) 
with a weight of 33/60, resulting in Brian's count going to 26.15 in the 
second count, and when those votes get transfered later, they'll get 
transferred at a weight (33/60)*(5/32) or whatever.

> I don't speak and understand english very well but from what I
> understood about the meaning of "close election" ours certainly is,
> we're electing 7 candidates over 10 with 211 ballots, there is no need
> to do the math to understand that the order of the ballots can change
> the results. Random transfer might work well when you have big numbers
> but can easily be unfair in a little election like this.
>
> PS. In case it wasn't clear, this is a +1 to Dave's challenge :-P

Thanks Filippo! Indeed, this is a close election, and the result might 
change depending on the transfers.

Cheers,
Dave.

--
Dave Neary
GNOME Foundation member
dneary gnome org