Re: 2017 update to the SPI voting algorithm for Board elections

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
Date: 2017-03-02 17:01:45
Message-ID: 22712.20473.175768.167646@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"):
> (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.)

Thanks.

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

OK.

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

Yes. If you don't think it's worthwhile I'll drop it.

> [Implementation discussion]
...
> 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.

Hrm.

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

Yes.

Well. I wrote my own implementation of the Scottish STV rules, based
on the Order, and fed a couple of existing SPI tally sheets into both
my ad-hoc reimplementation, and Debian's openstv. I arranged for my
program to generate output which could be compared to that from
openstv. The results were identical. Obviously this is not a
complete test but I am willing to tart up my software if you like, so
we can have two implementations and see if they agree.

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

There was test data for the software used for the Scottish system:
http://www.votingmatters.org.uk/RES/eSTV-Eval.pdf
I have sent two FOI requests to see if the Scottish Executive and/or
the Electoral Commission have it.
https://www.whatdotheyknow.com/request/test_data_for_scottish_single_tr
https://www.whatdotheyknow.com/request/test_data_for_scottish_single_tr_2

Thanks,
Ian.

Responses

Browse spi-general by date

  From Date Subject
Next Message Ian Jackson 2017-03-02 17:11:04 Re: 2017 update to the SPI voting algorithm for Board elections
Previous Message Jonathan McDowell 2017-03-02 10:13:15 Re: 2017 update to the SPI voting algorithm for Board elections