Re: Voting system for elections

I see we are still using Condorcet for the board elections.

As has been discussed here many times previously, Condorcet is a bad
system for multi-seat elections. Rather than electing a board whose
composition reflects, proportionately, the views of the electorate,
the majoritarian or consensus candidates (as applicable) will sweep
the board.

I have previously proposed that we should drop Condorcet in favour of
the Single Transferrable Vote.

Last time we had this conversation we got bogged down in a pile of
voting system wonkery.

I still think we should drop Condorcet in favour of STV. We should
drop it in favour of STV as defined by the UK Electoral Reform
Society, who have a clear description. The UK ERS rules have broad
legitimacy and standing through their adoption by many organisations.
(We'd obviously want to ignore the bits of the ERS definition which
talk about the handling of paper ballots.)

We should avoid getting distracted by arguments that some subtle
variant may be better. It is too late for this election but I think
it is imperative that we fix this for the next SPI board election.

This is especially true given that our variant of Condorcet is still
interpreting a ballot "1. Z 2. X" as not preferring Z or X to Y,
which is IMO an extremely serious deficiency in itself.

I therefore invite the Board candidates to say right now whether they
would support a change for the voting system to STV.

Thanks,
Ian.

--
Ian Jackson <ijackson(at)chiark(dot)greenend(dot)org(dot)uk> These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

On Mon, Jul 18, 2016 at 02:29:27PM +0100, Ian Jackson wrote:
> I see we are still using Condorcet for the board elections.
>
> As has been discussed here many times previously, Condorcet is a bad
> system for multi-seat elections. Rather than electing a board whose
> composition reflects, proportionately, the views of the electorate,
> the majoritarian or consensus candidates (as applicable) will sweep
> the board.
>
> I have previously proposed that we should drop Condorcet in favour of
> the Single Transferrable Vote.
>
> Last time we had this conversation we got bogged down in a pile of
> voting system wonkery.

Part of the problem is that this discussion only ever comes up during an
actual election process, when there is no possibility of a change being
made.

I don't have any objections to a change to STV; it might be interesting
to run previous votes through it to see how the outcome might have
differed. I don't have spare tuits at present[0] but if anyone wants to
provide some Python to implement an STVVS to match CondorcetVS I can
look at running.

J.

[0] Currently on backorder, expected in September.

--
She's the one for me. She's all I really need, oh yeah.

On 07/18/2016 06:38 AM, Jonathan McDowell wrote:
> On Mon, Jul 18, 2016 at 02:29:27PM +0100, Ian Jackson wrote:

> I don't have any objections to a change to STV; it might be interesting
> to run previous votes through it to see how the outcome might have
> differed. I don't have spare tuits at present[0] but if anyone wants to
> provide some Python to implement an STVVS to match CondorcetVS I can
> look at running.

I too don't have a problem with it.

JD

--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.

On 07/18/2016 06:29 AM, Ian Jackson wrote:
> As has been discussed here many times previously, Condorcet is a bad
> system for multi-seat elections. Rather than electing a board whose
> composition reflects, proportionately, the views of the electorate,
> the majoritarian or consensus candidates (as applicable) will sweep
> the board.

Given SPI's history, that sounds like a feature, not a bug.

Also, generally SPI elections don't involve much in the way of published
views.

Not saying that I love concordet, just that this doesn't feel much like
an argument for change.

--Josh

Hi Ian,

On 2016-07-18 09:29, Ian Jackson wrote:
> [...]

> This is especially true given that our variant of Condorcet is still
> interpreting a ballot "1. Z 2. X" as not preferring Z or X to Y,
> which is IMO an extremely serious deficiency in itself.

I fail to see how the system could infer any preference about Y from a ranking which does not mention Y, and I certainly do not see how this would constitute an extremely serious deficiency.

Condorcet is more targeted for democracies and it may not be ideal here, but I am not convinced that STV (which I do not remember precisely) would be better. STV would certainly better reflect the diversity of our views, but that does not mean it will lead to choices closer to the choices which votes from the whole electorate would yield.

[...]

--
Filipus Klutiero
http://www.philippecloutier.com

Filipus Klutiero writes ("Re: Voting system for elections"):
> On 2016-07-18 09:29, Ian Jackson wrote:
> This is especially true given that our variant of Condorcet is still
> interpreting a ballot "1. Z 2. X" as not preferring Z or X to Y,
> which is IMO an extremely serious deficiency in itself.
>
>
> I fail to see how the system could infer any preference about Y from
> a ranking which does not mention Y, and I certainly do not see how
> this would constitute an extremely serious deficiency.

Every other voting system anywhere on the planet treats a ballot
mentioning only X as preferring X to all other candidates.

Every other preferential voting system treats a ballot ranking X 1st,
and Y 2nd, as a preference for X or Y over all other candidates.

That is how voters expect these systems to work.

Our voting system treats a ballot mentioning only X as expressing no
preference whatsoever.

Ian.

On 2016-07-19 09:02, Ian Jackson wrote:
> Filipus Klutiero writes ("Re: Voting system for elections"):
>> On 2016-07-18 09:29, Ian Jackson wrote:
>> This is especially true given that our variant of Condorcet is still
>> interpreting a ballot "1. Z 2. X" as not preferring Z or X to Y,
>> which is IMO an extremely serious deficiency in itself.
>>
>>
>> I fail to see how the system could infer any preference about Y from
>> a ranking which does not mention Y, and I certainly do not see how
>> this would constitute an extremely serious deficiency.
> Every other voting system anywhere on the planet treats a ballot
> mentioning only X as preferring X to all other candidates.

Well, a preferential system should not *allow* such a ballot in the first place.

>
> Every other preferential voting system treats a ballot ranking X 1st,
> and Y 2nd, as a preference for X or Y over all other candidates.
>
> That is how voters expect these systems to work.
>
> Our voting system treats a ballot mentioning only X as expressing no
> preference whatsoever.

This particular concern seems to be a simple user interface issue. Our system should not allow a ballot mentioning a single option.
Evidently, the voting interface could use a lot of work.

I do not see a good reason to change the system in this concern.

>
> Ian.

--
Filipus Klutiero
http://www.philippecloutier.com

On Mon, Jul 18, 2016 at 02:29:27PM +0100, Ian Jackson wrote:
> I therefore invite the Board candidates to say right now whether they
> would support a change for the voting system to STV.

I'd want to understand the implications of the switch as applied to SPI better
than I currently do, but I'm not in theory opposed to it. I do like the idea of
prioritizing people everyone can live with over everyone's ideal candidate, but
I also like the idea of including more directors outside of SPI's dominant
groups (and indeed I ranked some ahead of myself in my vote). Whatever works
toward those goals might be worth switching to.

I also appreciate the option of giving incomplete rankings where I just say
something like "I prefer X to Y but haven't had a chance to look at the other
platforms so don't want to comment" - however, in practice, I've never actually
wanted to vote this way, so it might not be an important thing except as a
theoretical possibility. I do think it's a good idea to allow equal
preferences, like Debian does. However, neither system allows specifying all
possible combinations of preferences, so it's one of the many user experience
vs expressiveness tradeoffs that always arises in these contexts.

Since I think SPI has more urgent problems for the new board to primarily focus
on, the drive for presenting the issue to the board would need to come from
someone like Ian who feels strongly about it, with context presented outside of
an election cycle where it can be considered properly. It's a completely
reasonable thing to consider over the next year if that happens.

- Jimmy Kaplowitz
jimmy(at)debian(dot)org / jimmy(at)spi-inc(dot)org

>
> Thanks,
> Ian.
>
> --
> Ian Jackson <ijackson(at)chiark(dot)greenend(dot)org(dot)uk> These opinions are my own.
>
> If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
> a private address which bypasses my fierce spamfilter.
> _______________________________________________
> Spi-general mailing list
> Spi-general(at)lists(dot)spi-inc(dot)org
> http://lists.spi-inc.org/listinfo/spi-general

Jimmy Kaplowitz writes ("Re: Voting system for elections"):
> I'd want to understand the implications of the switch as applied to
> SPI better than I currently do, but I'm not in theory opposed to
> it. I do like the idea of prioritizing people everyone can live with
> over everyone's ideal candidate, but I also like the idea of
> including more directors outside of SPI's dominant groups (and
> indeed I ranked some ahead of myself in my vote). Whatever works
> toward those goals might be worth switching to.

I hope something like a tally sheet will be available after the
election.

Ian.

Jimmy Kaplowitz <jimmy(at)debian(dot)org> writes:

> I'd want to understand the implications of the switch as applied to SPI better
> than I currently do, but I'm not in theory opposed to it. I do like the idea of
> prioritizing people everyone can live with over everyone's ideal candidate, but
> I also like the idea of including more directors outside of SPI's dominant
> groups (and indeed I ranked some ahead of myself in my vote). Whatever works
> toward those goals might be worth switching to.

Here's a half-baked thought, for the sake of brainstorming: What if the
vote-counting software were to alternate between selecting Condorcet
winners and progressively reweighting ballots to discount those that
gave high ranks to winners that had already been selected? The problem
is coming up with a reasonable reweighting algorithm. Simplicity is a
big plus, in the interest of transparency, but there are other
considerations. In particular:

* How should the discount vary for having ranked a winner first, second,
third, etc.? What if a voter ranked any candidates equally? (Range
voting might make this question easier to address, but is a whole
separate can of worms.)

* Should discounts be rescaled so that the total weight of ballots under
consideration drops by a constant amount each round, as in STV?

* Are amateur election methods generally as inadvisable as amateur
cryptography? ;-)

--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?amu(at)monk(dot)mit(dot)edu

Folks,

Do we actually have more nominees running that we have spots? Because
if we don't this is all a pointless theoretical exercise.

--Josh

Josh berkus <josh(at)postgresql(dot)org> writes:

> Do we actually have more nominees running that we have spots? Because
> if we don't this is all a pointless theoretical exercise.

Per http://lists.spi-inc.org/pipermail/spi-announce/2016/000398.html:

| There are 13 candidates for six posts.

As noted elsewhere in this thread, it's obviously too late to change how
the current election is running, but IIRC there have been contested
elections reasonably often in the past, and I wouldn't be surprised to
see more.

--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?amu(at)monk(dot)mit(dot)edu

Hi Josh,

On Fri, Jul 22, 2016 at 02:22:32PM -0700, Josh berkus wrote:
> Do we actually have more nominees running that we have spots? Because
> if we don't this is all a pointless theoretical exercise.

This time around, we very much do - 13 candidates for 6 spots. Read our
platforms and vote. :) However nobody is taking about replacing the voting
system for the current election since the voting period is well underway. Let's
hope we'll have more vibrantly contested elections in the future.

- Jimmy Kaplowitz
jimmy(at)debian(dot)org / jimmy(at)spi-inc(dot)org

On 07/22/2016 02:35 PM, Jimmy Kaplowitz wrote:
> This time around, we very much do - 13 candidates for 6 spots. Read our
> platforms and vote. :) However nobody is taking about replacing the voting
> system for the current election since the voting period is well underway. Let's
> hope we'll have more vibrantly contested elections in the future.

I'm waiting to work out an issue with my login, which is why I asked.

--Josh Berkus

On Fri, Jul 22, 2016 at 02:48:59PM -0700, Josh berkus wrote:
> On 07/22/2016 02:35 PM, Jimmy Kaplowitz wrote:
> > This time around, we very much do - 13 candidates for 6 spots. Read our
> > platforms and vote. :) However nobody is taking about replacing the voting
> > system for the current election since the voting period is well underway. Let's
> > hope we'll have more vibrantly contested elections in the future.
>
> I'm waiting to work out an issue with my login, which is why I asked.

Ah, got it. I don't currently have the privileges to help, but someone in #spi
probably can assist. Try the password reset feature first just in case that
fixes it. In the meantime, I don't believe the platforms require any account to
read them, so you can at least think over your choices while getting the
technical issue addressed.

Good luck!

- Jimmy Kaplowitz
jimmy(at)debian(dot)org / jimmy(at)spi-inc(dot)org

Aaron M. Ucko writes ("Re: Voting system for elections"):
> Here's a half-baked thought, for the sake of brainstorming: What if the
> vote-counting software were to alternate between selecting Condorcet
> winners and progressively reweighting ballots to discount those that
> gave high ranks to winners that had already been selected? The problem
> is coming up with a reasonable reweighting algorithm. Simplicity is a
> big plus, in the interest of transparency, but there are other
> considerations. In particular:

I don't think SPI should be in the business of designing and then
adopting a bespoke election system.

Ian.

> I don't think SPI should be in the business of designing and then
> adopting a bespoke election system.

Indeed, getting voting systems right is highly technical and
mathematical, and remains an active area of research. (Observe the
current presidential election in the USA to see what happens when the
system is poorly designed.) Please please please do not design
something off the top of your head! That has about as much chance of
being a good voting system as someone naive to cryptography cobbling
together a new cryptosystem and the result being secure and efficient.

If we want to adopt a good voting system for proportional
representation, as already pointed out, Condorcet is not a contender,
as Condorcet is for electing a single winner. I would suggest that we
adopt a best-of-breed proportional representation system, namely RRV,
nicely documented and analyzed here: http://rangevoting.org/RRV.html

Cheers,

--Barak.

+1

I would suggest that we
> adopt a best-of-breed proportional representation system, namely RRV,
> nicely documented and analyzed here: http://rangevoting.org/RRV.html
>
> Cheers,
>
> --Barak
>
>

Hello,

If the members could come to a consensus on the type of voting we should
switch to, I would be more than happy to write the resolution.

Sincerely,

JD

--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.
Unless otherwise stated, opinions are my own.

I'm pretty impressed with RRV.

On Mon, Jul 25, 2016, 10:11 AM Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:

> Hello,
>
> If the members could come to a consensus on the type of voting we should
> switch to, I would be more than happy to write the resolution.
>
> Sincerely,
>
> JD
>
> --
> Command Prompt, Inc. http://the.postgres.company/
> +1-503-667-4564
> PostgreSQL Centered full stack support, consulting and development.
> Everyone appreciates your honesty, until you are honest with them.
> Unless otherwise stated, opinions are my own.
> _______________________________________________
> Spi-general mailing list
> Spi-general(at)lists(dot)spi-inc(dot)org
> http://lists.spi-inc.org/listinfo/spi-general
>

> If the members could come to a consensus on the type of voting we should
switch to, I would be more than happy to write the resolution.

+1

On 7/18/16 9:29 AM, Ian Jackson wrote:
> This is especially true given that our variant of Condorcet is still
> interpreting a ballot "1. Z 2. X" as not preferring Z or X to Y,
> which is IMO an extremely serious deficiency in itself.

I was told off-list that this was changed now:

https://github.com/u1f35c/spi-members/commit/330e3e0cadbfac6c0ea2421af4e900c6c58bc86d

On 25 July 2016 at 19:10, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
> If the members could come to a consensus on the type of voting we should
> switch to, I would be more than happy to write the resolution.

It seems like a few people seem to find the argument for RRV
convincing, and no one has objected. Does anyone want to voice an
opinion supporting anything else? To be honest, this is not exactly
the most important election in the world, and any system that performs
reasonably should be okay. So I can well understand the general lack
of intense discussion of this somewhat arcane issue.

If no one object, I'd suggest just rolling with an RRV resolution, and
see if anyone minds at that point. Because we should have something
sensible and robust in place prior to some future hypothetical big
voting fight...

Cheers,

--Barak.

Peter Eisentraut writes ("Re: Voting system for elections"):
> On 7/18/16 9:29 AM, Ian Jackson wrote:
> > This is especially true given that our variant of Condorcet is still
> > interpreting a ballot "1. Z 2. X" as not preferring Z or X to Y,
> > which is IMO an extremely serious deficiency in itself.
>
> I was told off-list that this was changed now:
>
> https://github.com/u1f35c/spi-members/commit/330e3e0cadbfac6c0ea2421af4e900c6c58bc86d

Good. Thanks, Noodles.

Ian.

--
Ian Jackson <ijackson(at)chiark(dot)greenend(dot)org(dot)uk> These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Barak A. Pearlmutter writes ("Re: Voting system for elections"):
> On 25 July 2016 at 19:10, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
> > If the members could come to a consensus on the type of voting we should
> > switch to, I would be more than happy to write the resolution.
>
> It seems like a few people seem to find the argument for RRV
> convincing, and no one has objected.

RRV is not AFAICT used anywhere else for political elections. Even
the web page you produced previously just produces one example of RRV
having been used elsewhere _at all_ and that's for selecting Oscar
nominees for one particular Oscar category.

SPI should adopt a system widely used elsewhere.

STV is the only widely adopted proportional voting system suitable for
SPI (the others are supplementary/additional member systems, and party
list systems).

STV is used:

In the UK:
* The Northern Ireland Assembly
* Northern Irish local government elections
* Scottish local government elections

In Australia:
* The Australian federal Senate and federal House of Representatives
* The legislative assemblies (etc.) of all the states etc. (New South
Wales, Victoria, Queensland, Western Australia, South Australia,
Tasmania, the Australian Capital Territory, the Northern Territory)
* (Many?) Australian local councils

(and then I got bored.)

https://en.wikipedia.org/wiki/History_and_use_of_the_single_transferable_vote

> If no one object, I'd suggest just rolling with an RRV resolution, and
> see if anyone minds at that point. Because we should have something
> sensible and robust in place prior to some future hypothetical big
> voting fight...

SPI should adopt STV.

Ian.

--
Ian Jackson <ijackson(at)chiark(dot)greenend(dot)org(dot)uk> These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Barak A. Pearlmutter writes ("Re: Voting system for elections"):
> It seems like a few people seem to find the argument for RRV
> convincing, and no one has objected.

I feel the need to repost here, an article I posted to spi-private on
the 4th of August:

From: Ian Jackson <ijackson(at)chiark(dot)greenend(dot)org(dot)uk>
To:
Cc: spi-private(at)lists(dot)spi-inc(dot)org
Subject: Re: [Spi-private] SPI board election method, reanalysis of 2016
election
Date: Thu, 4 Aug 2016 02:15:57 +0100

[ Someone wrote asking for a: ]
> [ detailed set of analysis criteria of multi-winner voting systems ]
[ (quote redacted -iwj 16.8.16) ]

SPI should not be in the business of detailed analysis of voting
systems, let alone the development of novel voting systems. Nor
should SPI adopt a system which is highly unusual.

There is only one multi-winner proportional voting system that makes
sense for SPI [1] and has nontrivial adoption in the world at large.
That system is STV.

https://en.wikipedia.org/wiki/Proportional_representation

[1] There are a handful of other common proportional multi-winner
systems, including Additional Member systems, and party list PR, but
they are obviously inappropriate for us.

The right direction for this conversation is a discussion of which
other respected institution's specific set of STV rules (answers to
the edge cases) we should adopt. We would like one which has a clear
description, from an authoritative source.

Ideally we want a variant of which there are already one or more
computerised implementations. (Even if we end up writing our own
computer implementation, an existing program will provide a useful
check and perhaps even come with some test vectors.)

Having done another set of searches I would suggest that we should
adopt Scottish STV. That is, the STV which is used in Scotland to
elect local councils. Here it is laid out in the legislation:
http://www.legislation.gov.uk/ssi/2007/42/schedule/1/part/III/crossheading/counting-of-votes/made
The rules on actual counting are paragraphs 45-52.
I also found this detailed description with examples:
http://www.votingmatters.org.uk/RES/STV-WIGM.pdf

Allegedly this is implemented in OpenVote:
https://packages.debian.org/jessie/openstv
https://github.com/OpenTechStrategies/openstv
(now taken proprietary but the Free version remains available,
including version 1.6 in Debian.)

Thus this system has a clear and authoritative statement of the rules,
and seems to have at least one computerised implementation.

Or we could consider following the lead of the Apache Software
Foundation. They use a Meek variant of STV and their page here
suggests that they have found at least two implemnetations (although
the fact that they've forked one of them isn't encouraging):
https://wiki.apache.org/general/BoardVoting

I haven't found (so far) a clear statement of the rules, in prose.
Wikipedia suggests that New Zealand uses a version of Meek STV (and
that Stack Exchange does too for some purposes), but I'm not sure if
they're the same.

I also found this list of tools:
http://www.accuratedemocracy.com/z_tools.htm

[ irrelevant section from -private deleted -iwj 16.8.16 ]

Ian.

--
Ian Jackson <ijackson(at)chiark(dot)greenend(dot)org(dot)uk> These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

> SPI should adopt a system widely used elsewhere.
>
> STV is the only widely adopted proportional voting system suitable for
> SPI (the others are supplementary/additional member systems, and party
> list systems).

I agree that STV is a pretty reasonable system, in fact it is the best
widely-deployed system appropriate for non-party-list proportional
representation. However, living as I do in the Republic of Ireland, I
have some personal experience with pathologies of STV which are
addressed by RRV. The mathematical analyses of RRV have convinced me
that RRV basically dominates STV, in that although RRV does have some
pathologies (as it must, due to Arrow's Theorem etc) its pathologies
are a strict subset of those of STV, and it cures the most
egregious-in-practice pathologies of STV.

Let me describe two STV pathologies that actually happened in the last
couple years, and certainly raised my eyebrows.

First, the result of an election can depend on the order of ballots.
In one case, the order was scrambled during a recount, resulting in
uncertainty about the correct result. Strategic re-ordering of ballots
is an actual issue. The most common attempt to address this is an
initial random shuffle, with the consequent order religiously
preserved for purposes of replication.

Second, there was a case where (to simplify) candidate X in a Dublin
precinct sent around a circular asking their supporters to list X
second on their ballots and Y first, where Y was a candidate with
ostensibly no hope of winning. This was to serve to increase the power
of these ballots. My native Irish friends found this a delightful
tale, particularly with all the fascinating details filled in and
appropriately embellished. Perhaps it is. But it didn't make me more
of an STV fan.

Cheers,

--Barak.
--
Barak A. Pearlmutter <barak(at)pearlmutter(dot)net> http://barak.pearlmutter.net

PS https://en.wikipedia.org/wiki/Issues_affecting_the_single_transferable_vote

Barak A. Pearlmutter writes ("Re: Voting system for elections"):
> Let me describe two STV pathologies that actually happened in the last
> couple years, and certainly raised my eyebrows.
>
> First, the result of an election can depend on the order of ballots.
> In one case, the order was scrambled during a recount, resulting in
> uncertainty about the correct result. Strategic re-ordering of ballots
> is an actual issue. The most common attempt to address this is an
> initial random shuffle, with the consequent order religiously
> preserved for purposes of replication.

This seems to be a consequence of the use of the (ancient) Hare method
for transferring ballots from a winning candidate's surplus: ie,
choosing ballots at random. I don't think anyone would propose
deploying such a system today.

Scottish STV (which is what I'm advocating as a concrete proposal)
uses fractional weight transfers and does not depend on the order of
ballots.

http://www.legislation.gov.uk/ssi/2007/42/schedule/1/part/III/crossheading/counting-of-votes/made

> Second, there was a case where (to simplify) candidate X in a Dublin
> precinct sent around a circular asking their supporters to list X
> second on their ballots and Y first, where Y was a candidate with
> ostensibly no hope of winning. This was to serve to increase the power
> of these ballots. My native Irish friends found this a delightful
> tale, particularly with all the fascinating details filled in and
> appropriately embellished. Perhaps it is. But it didn't make me more
> of an STV fan.

It is difficult to know from what you've said whether this was really
advantageous for X's voters. It is true that this kind of tactical
voting ("free riding") can sometimes be problem in STV. But from the
description of RRV you have linked to, I don't see how it solves this
free riding problem. That is, a similar tactical approach would tend
to be possible, in similar circumstances, when RRV was used.

And range voting suffers from two additional much more serioues linked
tactical voting problems: to have the most effect, each voter should
choose a cutoff point, and vote all candidates either 0% or 100%
depending whether they are worse than the cutoff. Where to place the
cutoff (ie how many candidates to vote 100%) depends on a deep
understanding of the likely behaviour of the other voters.

Your suggestion that SPI should adopt RRV, rather than STV, would be
more convincing if:

- RRV was adopted elsewhere. It's not. Everyone else is using
STV. (Or maybe FPTP, AMS or party lists.)

- Neutral electoral reform campaigners usually advocated RRV.
They don't. They usually advocate STV.

- Anyone explained how RRV solves the free riding problem which is
the most generally touted weakness of STV. Even the RRV web
page on rangevoting.org does not do so. I think RRV does not
solve this problem. (Indeed the problem is probably inherent.)

- RRV was advocated for use as a proportional multi-winner system by
people who favoured usually-Condorcet-satisfying systems (eg
explicitly Condorcet-based systems like Debian's, or even AV/IRV)
for single-winner votes.

Ian.

--
Ian Jackson <ijackson(at)chiark(dot)greenend(dot)org(dot)uk> These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

On 08/16/2016 07:04 AM, Ian Jackson wrote:
> Barak A. Pearlmutter writes ("Re: Voting system for elections"):
>> On 25 July 2016 at 19:10, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:

> SPI should adopt a system widely used elsewhere.

Correct.

>
> STV is the only widely adopted proportional voting system suitable for
> SPI (the others are supplementary/additional member systems, and party
> list systems).

I don't follow voting systems in anyway until this last election and
funny enough, I ran into open source[1] project that is executing a vote
right now, using STV.

Sincerely,

JD

1. PHP-FIG

--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.
Unless otherwise stated, opinions are my own.

On 7/18/16 9:29 AM, Ian Jackson wrote:
> As has been discussed here many times previously, Condorcet is a bad
> system for multi-seat elections. Rather than electing a board whose
> composition reflects, proportionately, the views of the electorate,
> the majoritarian or consensus candidates (as applicable) will sweep
> the board.

I have a concern about this:

If, for example, there were an issue that sharply divides the SPI
membership say 66% to 33%, an STV election would elect 6 board members
in favor of A and 3 in favor of B, whereas a Condorcet election might
elect 9 in favor of A. The problem with the STV board would be that
they would constantly disagree with each other instead of getting work done.

An analogy in "real" politics is: A parliament should generally reflect
the population's wishes proportionally, but the executive is generally
drawn only from one or a few aligned parties.

Maybe this isn't a problem in practice, or maybe you/some actually want
to the board to work that way, but I think we should consider what the
nature of the board is or should be, and which election method best
realizes that.

Peter Eisentraut writes ("Re: Voting system for elections"):
> On 7/18/16 9:29 AM, Ian Jackson wrote:
> > As has been discussed here many times previously, Condorcet is a bad
> > system for multi-seat elections. Rather than electing a board whose
> > composition reflects, proportionately, the views of the electorate,
> > the majoritarian or consensus candidates (as applicable) will sweep
> > the board.
>
> I have a concern about this:
>
> If, for example, there were an issue that sharply divides the SPI
> membership say 66% to 33%, an STV election would elect 6 board members
> in favor of A and 3 in favor of B, whereas a Condorcet election might
> elect 9 in favor of A. The problem with the STV board would be that
> they would constantly disagree with each other instead of getting work done.

I hope we would only elect grown-ups to the board. 6 out of 9 is of
course still a majority.

> An analogy in "real" politics is: A parliament should generally reflect
> the population's wishes proportionally, but the executive is generally
> drawn only from one or a few aligned parties.

Most British membership-run NGOs elect their board by STV. It hasn't
led to this kind of disaster.

Also, and sorry to keep coming back to this, but it is a key point:

> > SPI should adopt a system widely used elsewhere.

AFAIAA no other organisation elects a multi-member board or committee
using repeated-Condorcet.

(Nor AFAIAA has this multi-winner repeated-Condorcet even ever been
proposed in the academic literature) We have invented it, and adopted
it, almost by accident - I think just by analogy with Debian's use of
Condorcet for single-winner elections.

> Maybe this isn't a problem in practice, or maybe you/some actually want
> to the board to work that way, but I think we should consider what the
> nature of the board is or should be, and which election method best
> realizes that.

It would be nice if we had a board election system which didn't
produce Debian Debian Debian Debian out of a mixed electorate.

Ian.
(in the context of SPI, clearly most closely associated with Debian)

--
Ian Jackson <ijackson(at)chiark(dot)greenend(dot)org(dot)uk> These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

On 08/16/2016 08:14 AM, Peter Eisentraut wrote:
> On 7/18/16 9:29 AM, Ian Jackson wrote:
>> As has been discussed here many times previously, Condorcet is a bad
>> system for multi-seat elections. Rather than electing a board whose
>> composition reflects, proportionately, the views of the electorate,
>> the majoritarian or consensus candidates (as applicable) will sweep
>> the board.
>
> I have a concern about this:
>
> If, for example, there were an issue that sharply divides the SPI
> membership say 66% to 33%, an STV election would elect 6 board members
> in favor of A and 3 in favor of B, whereas a Condorcet election might
> elect 9 in favor of A. The problem with the STV board would be that
> they would constantly disagree with each other instead of getting work done.

It is likely that the 66% is going to rule the board anyway. In fact, we
saw that happen over the last several years. The advantage is that there
will be *some* of the 66% who will realize the importance of getting
certain things done (like Zobel helping the Treasurer finally get into
an accounting system). Further you are going to have some lap over from
the 33%. You will get people saying, "Hey, that actually makes sense."
from the 66% that was influenced by the 33%.

>
> An analogy in "real" politics is: A parliament should generally reflect
> the population's wishes proportionally, but the executive is generally
> drawn only from one or a few aligned parties.

Correct, our parliament is our board. Our officers are our executive branch.

>
> Maybe this isn't a problem in practice, or maybe you/some actually want
> to the board to work that way, but I think we should consider what the
> nature of the board is or should be, and which election method best
> realizes that.

Progress is made through a compromise that everyone hates and loves at
the same time.

Sincerely,

JD

--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.
Unless otherwise stated, opinions are my own.

Peter Eisentraut writes ("Re: Voting system for elections"):
> On 7/18/16 9:29 AM, Ian Jackson wrote:
> > As has been discussed here many times previously, Condorcet is a bad
> > system for multi-seat elections. Rather than electing a board whose
> > composition reflects, proportionately, the views of the electorate,
> > the majoritarian or consensus candidates (as applicable) will sweep
> > the board.
>
> I have a concern about this:
>
> If, for example, there were an issue that sharply divides the SPI
> membership say 66% to 33%, an STV election would elect 6 board members
> in favor of A and 3 in favor of B, whereas a Condorcet election might
> elect 9 in favor of A. The problem with the STV board would be that
> they would constantly disagree with each other instead of getting work done.

And, once again I feel the need to repost an article I posted to
spi-private:

From: Ian Jackson <ijackson(at)chiark(dot)greenend(dot)org(dot)uk>
To:
Cc: spi-private(at)lists(dot)spi-inc(dot)org
Subject: Re: [Spi-private] Vote form concerns
Date: Thu, 4 Aug 2016 15:54:40 +0100

Anthony Towns writes ("Re: [Spi-private] Vote form concerns"):
> On Thu, Jul 21, 2016 at 04:14:45PM +0100, Ian Jackson wrote:
> [on adopting STV rather than repeated Condorcet]
> > Hopefully in SPI we won't get into some kind of ideological split.
> > But suppose we did.
>
> [ if it happened, would it be better to to have an ideologically
> divided board, or to have a homogenous board, and let the dissenters
> split off into a different organisation? ]
[ (quote reworded to redact -iwj 16.8.16) ]

The situation I described was an example, with a deliberately
exaggerated political difference. But the same problem applies in any
election, even if there is no big irreconcilable ideological
difference. It's just more subtle.

In SPI the most obvious "clumping" of candidates and voters is whether
they are primarily associated with Debian. We have made good progress
in making SPI more diverse in that sense. But because our voting
system exaggerates the influence of any majority, it exaggerates the
influence of those of our contributing members who are familiar with,
and support, the board candidates with a Debian background.

And, in direct answer to your question: in the absence of difficult
ideological problems, a homogenous board is *much* less desirable.
It is an established principle of good governance that diversity, on a
governing body, is a good idea.

If the minority's ideas are wrongheaded, then presumably they won't be
able to carry the board with them. But a minority often has a useful
different perspective.

(As an aside, I think there is nothing wrong with voters preferring
candidates that they are familiar with. An important part of being a
good candidate for the SPI board is to have a good reputation,
particularly in one's "origin" project(s). That does not mean that
board members from different backgrounds cannot work together. On the
contrary I think we have demonstrated that largely they can.)

[ irrelevancies from -private deleted -iwj 16.8.16 ]

Ian.

--
Ian Jackson <ijackson(at)chiark(dot)greenend(dot)org(dot)uk> These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Which STV software has both:

1. open source license
2. recent commits

On Tue, Aug 16, 2016 at 10:28 AM, Ian Jackson <
ijackson(at)chiark(dot)greenend(dot)org(dot)uk> wrote:

> Peter Eisentraut writes ("Re: Voting system for elections"):
> > On 7/18/16 9:29 AM, Ian Jackson wrote:
> > > As has been discussed here many times previously, Condorcet is a bad
> > > system for multi-seat elections. Rather than electing a board whose
> > > composition reflects, proportionately, the views of the electorate,
> > > the majoritarian or consensus candidates (as applicable) will sweep
> > > the board.
> >
> > I have a concern about this:
> >
> > If, for example, there were an issue that sharply divides the SPI
> > membership say 66% to 33%, an STV election would elect 6 board members
> > in favor of A and 3 in favor of B, whereas a Condorcet election might
> > elect 9 in favor of A. The problem with the STV board would be that
> > they would constantly disagree with each other instead of getting work
> done.
>
> And, once again I feel the need to repost an article I posted to
> spi-private:
>
> From: Ian Jackson <ijackson(at)chiark(dot)greenend(dot)org(dot)uk>
> To:
> Cc: spi-private(at)lists(dot)spi-inc(dot)org
> Subject: Re: [Spi-private] Vote form concerns
> Date: Thu, 4 Aug 2016 15:54:40 +0100
>
> Anthony Towns writes ("Re: [Spi-private] Vote form concerns"):
> > On Thu, Jul 21, 2016 at 04:14:45PM +0100, Ian Jackson wrote:
> > [on adopting STV rather than repeated Condorcet]
> > > Hopefully in SPI we won't get into some kind of ideological split.
> > > But suppose we did.
> >
> > [ if it happened, would it be better to to have an ideologically
> > divided board, or to have a homogenous board, and let the dissenters
> > split off into a different organisation? ]
> [ (quote reworded to redact -iwj 16.8.16) ]
>
> The situation I described was an example, with a deliberately
> exaggerated political difference. But the same problem applies in any
> election, even if there is no big irreconcilable ideological
> difference. It's just more subtle.
>
> In SPI the most obvious "clumping" of candidates and voters is whether
> they are primarily associated with Debian. We have made good progress
> in making SPI more diverse in that sense. But because our voting
> system exaggerates the influence of any majority, it exaggerates the
> influence of those of our contributing members who are familiar with,
> and support, the board candidates with a Debian background.
>
> And, in direct answer to your question: in the absence of difficult
> ideological problems, a homogenous board is *much* less desirable.
> It is an established principle of good governance that diversity, on a
> governing body, is a good idea.
>
> If the minority's ideas are wrongheaded, then presumably they won't be
> able to carry the board with them. But a minority often has a useful
> different perspective.
>
> (As an aside, I think there is nothing wrong with voters preferring
> candidates that they are familiar with. An important part of being a
> good candidate for the SPI board is to have a good reputation,
> particularly in one's "origin" project(s). That does not mean that
> board members from different backgrounds cannot work together. On the
> contrary I think we have demonstrated that largely they can.)
>
> [ irrelevancies from -private deleted -iwj 16.8.16 ]
>
> Ian.
>
> --
> Ian Jackson <ijackson(at)chiark(dot)greenend(dot)org(dot)uk> These opinions are my own.
>
> If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
> a private address which bypasses my fierce spamfilter.
> _______________________________________________
> Spi-general mailing list
> Spi-general(at)lists(dot)spi-inc(dot)org
> http://lists.spi-inc.org/listinfo/spi-general
>

On Mon, Aug 15, 2016 at 10:02:00AM -0400, Peter Eisentraut wrote:
> On 7/18/16 9:29 AM, Ian Jackson wrote:
> > This is especially true given that our variant of Condorcet is still
> > interpreting a ballot "1. Z 2. X" as not preferring Z or X to Y,
> > which is IMO an extremely serious deficiency in itself.
> I was told off-list that this was changed now:
> https://github.com/u1f35c/spi-members/commit/330e3e0cadbfac6c0ea2421af4e900c6c58bc86d

This seems like it doesn't actually change the way votes are counted,
though it does do most of the work so that someone can easily make that
change later? Or am I misunderstanding?

Cheers,
aj

On Wed, Aug 17, 2016 at 12:57:09PM +1000, Anthony Towns wrote:
> On Mon, Aug 15, 2016 at 10:02:00AM -0400, Peter Eisentraut wrote:
> > On 7/18/16 9:29 AM, Ian Jackson wrote:
> > > This is especially true given that our variant of Condorcet is still
> > > interpreting a ballot "1. Z 2. X" as not preferring Z or X to Y,
> > > which is IMO an extremely serious deficiency in itself.
> > I was told off-list that this was changed now:
> > https://github.com/u1f35c/spi-members/commit/330e3e0cadbfac6c0ea2421af4e900c6c58bc86d
>
> This seems like it doesn't actually change the way votes are counted,
> though it does do most of the work so that someone can easily make that
> change later? Or am I misunderstanding?

You are correct; there is another change required so that the system
knows a) which voting system is in use for a given vote and b) how many
winners there should be. These changes will also provide the ground work
for adding any other voting system that gets decided on.

J.

--
101 things you can't have too much of : 17 - Money.

Susan Spencer writes ("Re: Voting system for elections"):
> Which STV software has both:
>
> 1. open source license
> 2. recent commits

I think asking for recent commits is not really sensible. In general
the meme that software is only useable, or only of high quality, if it
is constantly being modified is harmful. There are many programs I
use frequently which are hardly ever modified. They provide a
pleasing level of stability and reliability.

To demonstrate this point, in direct answer to your question:

http://www.chiark.greenend.org.uk/ucgi/~ian/git?p=appendix-a6.git;a=blob;f=compute-scottish-stv;h=98ec3082bd92de269a79af720f4ba8472c8f163a;hb=HEAD

I wrote that on Sunday afternoon.

(Commits in that repo since then were simply to enable me to
mechanically compare its functionality with OpenSTV. I am pleased to
be able to report that when I used SPI's recent board election as a
test case, OpenSTV and my own program produced identical results. Ie,
I did not need to fix any further bugs in either implementation.)

Of course my tool is not really productised or packaged. But that
just goes to show that `has recent commits' is not the best criterion
for software quality. https://packages.qa.debian.org/o/openstv.html
seems to me to show a package in reasonably good shape.

If SPI wants to use STV for future board elections I will happily
reimplement Scottish STV again in whatever language, and with whatever
input and output forwards, are thought desirable.

Ian.

Well, 'recent commits' is useful only as an imperfect indicator of whether
a project is dead or alive.
It isn't an absolute to use as a checkbox item for evaluating the
appropriateness of a software solution.
Rather it is good to know in case it stops working due to upstream issues
or any variety of factors.
It is part of the 'due diligence' research phase of choosing a software
solution.

On Tue, Aug 23, 2016 at 8:10 AM, Ian Jackson <
ijackson(at)chiark(dot)greenend(dot)org(dot)uk> wrote:

> Susan Spencer writes ("Re: Voting system for elections"):
> > Which STV software has both:
> >
> > 1. open source license
> > 2. recent commits
>
> I think asking for recent commits is not really sensible. In general
> the meme that software is only useable, or only of high quality, if it
> is constantly being modified is harmful. There are many programs I
> use frequently which are hardly ever modified. They provide a
> pleasing level of stability and reliability.
>
> To demonstrate this point, in direct answer to your question:
>
> http://www.chiark.greenend.org.uk/ucgi/~ian/git?p=
> appendix-a6.git;a=blob;f=compute-scottish-stv;h=
> 98ec3082bd92de269a79af720f4ba8472c8f163a;hb=HEAD
>
> I wrote that on Sunday afternoon.
>
> (Commits in that repo since then were simply to enable me to
> mechanically compare its functionality with OpenSTV. I am pleased to
> be able to report that when I used SPI's recent board election as a
> test case, OpenSTV and my own program produced identical results. Ie,
> I did not need to fix any further bugs in either implementation.)
>
> Of course my tool is not really productised or packaged. But that
> just goes to show that `has recent commits' is not the best criterion
> for software quality. https://packages.qa.debian.org/o/openstv.html
> seems to me to show a package in reasonably good shape.
>
> If SPI wants to use STV for future board elections I will happily
> reimplement Scottish STV again in whatever language, and with whatever
> input and output forwards, are thought desirable.
>
> Ian.
>

Susan Spencer writes ("Re: Voting system for elections"):
> Well, 'recent commits' is useful only as an imperfect indicator of
> whether a project is dead or alive. It isn't an absolute to use as
> a checkbox item for evaluating the appropriateness of a software
> solution. Rather it is good to know in case it stops working due to
> upstream issues or any variety of factors.

It can't stop working due to "upstream issues" if upstream are not
making changes. Looking at the state in Debian, it stopped working
"recently" because of churn in some Python libraries, but this was
fairly easily fixed by a Debian contributor.

> It is part of the 'due diligence' research phase of choosing a software
> solution.

I agree that if the program were obviously in need of major work, and
there was no upstream, then this would be a problem. But this is not
the case here.

Ian.