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

• From: Dave Neary <dneary gnome org>
• To: Filippo Argiolas <fargiolas gnome org>
• Cc: foundation-list <foundation-list gnome org>, elections gnome org, GNOME Foundation Membership Committee <membership-committee gnome org>, michael meeks novell com
• Subject: Re: GNOME Board of Directors Foundation Elections Spring 2009 - Preliminary results
• Date: Fri, 26 Jun 2009 11:23:19 +0200

```Hi,

A small correction to explain exactly how random transfers work:

Filippo Argiolas wrote:
```
```- with Random Transfer, 20 ballots are picked randomly (assuming those
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
```

• Follow-Ups:
• References: