Re: 2017 update to the SPI voting algorithm for Board elections [and 1 more messages] [and 1 more messages]

From: Ian Jackson <ijackson(at)chiark(dot)greenend(dot)org(dot)uk>
To: Jonathan McDowell <noodles(at)earth(dot)li>
Cc: spi-general(at)lists(dot)spi-inc(dot)org
Subject: Re: 2017 update to the SPI voting algorithm for Board elections [and 1 more messages] [and 1 more messages]
Date: 2017-02-28 15:32:11
Message-ID: 22709.38907.540202.197141@chiark.greenend.org.uk
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: spi-general

Jonathan McDowell writes ("Re: 2017 update to the SPI voting algorithm for Board elections [and 1 more messages]"):
Jonathan McDowell writes ("Re: 2017 update to the SPI voting algorithm for Board elections"):
> Actually it turns out that OpenSTV is written in Python and largely
> written in a way that means it might be possible to shoe-horn it into
> the existing members website as a way of processing votes.

Yes. At the very least, it can be called as a command-line program.
The interface is a bit clunky but tolerable.

> However it appears to have been taken proprietary by upstream, with
> Conservancy having the latest GPL copy and stating it is
> unmaintained:
>
> https://github.com/Conservatory/openstv

I don't think we need it to be "maintained" :-). I tested the Debian
package and it worked for me and gave the same answers as my
ad-hoc reimplementation.

The ballot counting software only needs to be fed pre-prepared inputs,
so it is not exposed to hostile data. Therefore it doesn't need
security updates. It would need updates if we discovered a bug in its
implementation of our chosen voting system.

> I still think specifying the method of implementation in the board
> resolution is not desirable, even if it turns out OpenSTV is the
> appropriate way to go at present.

I agree. I'm sorry that my draft resolution gave the impression that
I was trying to specify that.

Let me try a different wording for that paragraph. How about this:

7. The practical implementation will be by means of software; for
example, perhaps the openstv package in Debian. The choice of
software is up to the Secretary. However, any differences between
the Rules in the Order, and whatever software implementation is
chosen, are to be resolved in favour of the Rules.

I do think it is important to declare that it is the prose rules which
definitive, not the software.

What do you think of another paragraph like this:

The Secretary's current practice is to privately issue each voter
with a private token, by construction verifiably distinct from
that of any other voter; and to publish alongside the results an
anonymised tally sheet listing every ballot paper and
corresponding token. This allows everyone to check that their own
vote has been included in the tally, and to verify that the count
has been conducted properly. The downwide is that each voter is
able to easily subvert the secrecy of their own ballot, but with
distance voting that is very hard to prevent. The Secretary's
practice is to continue.

> (I'm prepared to try and author a suitable ScottishSTV implementation
> that fits in the current framework, but it will require either [or
> ideally both] careful code review by someone else or a comprehensive set
> of test vectors to provide confidence I have done so correctly.)

I think it would be better to use an existing implementation -
preferably, an old one.

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.

Responses

Browse spi-general by date

  From Date Subject
Next Message Dimitri John Ledkov 2017-02-28 15:33:18 Re: 2017 update to the SPI voting algorithm for Board elections [and 1 more messages]
Previous Message Jonathan McDowell 2017-02-28 12:07:44 Re: 2017 update to the SPI voting algorithm for Board elections