2017 update to the SPI voting algorithm for Board elections

[Jonathan McDowell]

(I have re-ordered this reply to try and cover the issues relating
 directly to the wording of the resolution first, and moving the less
 time critical discussion about implementation to the end.)

On Tue, Feb 28, 2017 at 03:32:11PM +0000, Ian Jackson wrote:
> Jonathan McDowell writes ("Re: 2017 update to the SPI voting algorithm
> for Board elections"):
>
> > 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.

I think that's a much better wording for the paragraph. I agree we want
the Order to be the authoritative version of the rules implemented.

> 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 not really sure it adds anything to the matter at hand. It seems to
only be documenting the current practice?

[Implementation discussion]

> > (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.

I agree the use of an existing implementation, particularly one that
offers a range of voting methods, is preferable. I think "widely and
actively used" are better criteria than age of the code base in
question, in terms of the chances of any issues with the implementation
being discovered rather than lying dormant. That, and all of the below,
said, I think that starting out with the hope that OpenSTV will provide
a suitable basis for implementation of the resolution is not
unreasonable.

> > 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.

I think that's very much a measure of last resort; a programmatic
interface to the Python modules involved would seem a much more robust
solution. From a deployment perspective the Debian package annoyingly
pulls in wx and all its associated dependencies, but that can be worked
around.

> > 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 agree the inputs are under tight control of the membership system but
I'm less worried about the security than the reliability of the
implementation; is there confidence that OpenSTV has been deployed for
use in Scottish STV and found to be reliable? I don't think we want to
run a couple of elections and then discover that we've been using a
buggy implementation and have to figure out how to fix it ourselves.

(It would be nice if the Scottish local election voting data was
 available to provide a suitable set of test vectors, but I couldn't
 even find any alternative sources of such test data.)

J.

-- 
Revd Jonathan McDowell, ULC | Let's burn this world down.