From jimmy at spi-inc.org Sun Feb 12 23:57:29 2017 From: jimmy at spi-inc.org (Jimmy Kaplowitz) Date: Sun, 12 Feb 2017 18:57:29 -0500 Subject: Revising the SPI bylaws: third draft Message-ID: <20170212235729.GV3725@kaplowitz.org> Hi SPI members, I've attached to this email the third draft of a complete rewrite of SPI bylaws, which have long been known to be flawed. Both prior drafts were discussed extensively on this list - links and context are below. We're primarily trying to update our legalese to be clearer and to reflect current practice. Please indicate whether you'd be open to voting for this revised version, or indicate any further revisions you'd like. We currently have an onerous amendment threshold, so to help us gauge opinion, please speak up either way. Full explanation: Back in July of last year, Bdale started an effort to overhaul SPI's bylaws, aiming to fix several longstanding problems with the current bylaws: - the bylaws do not comprehend the idea of board meetings on IRC - the rules the board voting by email are intractable - there is a hard requirement to hold an annual general meeting on the first day of July, which is rarely convenient due to national holidays, etc - in a number of places, the bylaws seem to contradict themselves - the board election rules make it hard to maintain a staggered election cycle for the board We've attempted to fix the existing wording in the past, but those efforts never went anywhere. It was a mess of a starting point. Given how badly suited the existing wording was, Bdale had the Software Freedom Law Center prepare a new draft from scratch to reflect existing practice in a clear and legal way, proposed here: http://lists.spi-inc.org/pipermail/spi-general/2016-July/003437.html A useful discussion followed on-list with lots of substantive comments. Some months later, I collected the feedback and offered a second draft here, along with a narrative of what I changed from Bdale's draft: http://lists.spi-inc.org/pipermail/spi-general/2016-November/003583.html The draft I've attached to this email is almost identical to the second draft, but addresses the one pending bit of feedback by adding a requirement for a board meeting attendance policy, at the end of Sections 5 and 8 of Article IV. We already have such a policy, but the current bylaws don't require one. If the membership thinks this draft is reasonable and is willing to support it, I'd love to send it off to our lawyers for any wording tweaks from them and then vote on the output of that. Based on the current bylaws' onerous rules for amendment, we'd need yes votes from 2/3 of contributing members, so please speak up to help us gauge reaction. Of course, if further alterations are needed before a vote, please don't hesitate to raise concerns. I haven't forgotten the request to switch from OpenDocument (source) / PDF (output) to Markdown or similar git-friendly formats. We'll deal with the hassle of reformatting once we have approved new bylaws. Looking forward to hearing your thoughts! - Jimmy Kaplowitz jimmy at spi-inc.oirg -------------- next part -------------- A non-text attachment was scrubbed... Name: spi-draft-bylaws_2017-02-12.pdf Type: application/pdf Size: 63086 bytes Desc: not available URL: From josh at postgresql.org Mon Feb 13 17:08:01 2017 From: josh at postgresql.org (Josh berkus) Date: Mon, 13 Feb 2017 09:08:01 -0800 Subject: Revising the SPI bylaws: third draft In-Reply-To: <20170212235729.GV3725@kaplowitz.org> References: <20170212235729.GV3725@kaplowitz.org> Message-ID: <369916c7-e381-0530-91c4-6367a84c9f67@postgresql.org> On 02/12/2017 03:57 PM, Jimmy Kaplowitz wrote: > If the membership thinks this draft is reasonable and is willing to > support it, I'd love to send it off to our lawyers for any wording > tweaks from them and then vote on the output of that. +1, let's do this. From taralx at gmail.com Mon Feb 13 17:43:12 2017 From: taralx at gmail.com (JP Sugarbroad) Date: Mon, 13 Feb 2017 17:43:12 +0000 Subject: Revising the SPI bylaws: third draft In-Reply-To: <369916c7-e381-0530-91c4-6367a84c9f67@postgresql.org> References: <20170212235729.GV3725@kaplowitz.org> <369916c7-e381-0530-91c4-6367a84c9f67@postgresql.org> Message-ID: On Mon, Feb 13, 2017, 9:08 AM Josh berkus wrote: > On 02/12/2017 03:57 PM, Jimmy Kaplowitz wrote: > > If the membership thinks this draft is reasonable and is willing to > > support it, I'd love to send it off to our lawyers for any wording > > tweaks from them and then vote on the output of that. > > +1, let's do this. > I'd vote for it. - JP > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jd at commandprompt.com Mon Feb 13 17:48:05 2017 From: jd at commandprompt.com (Joshua D. Drake) Date: Mon, 13 Feb 2017 09:48:05 -0800 Subject: Revising the SPI bylaws: third draft In-Reply-To: References: <20170212235729.GV3725@kaplowitz.org> <369916c7-e381-0530-91c4-6367a84c9f67@postgresql.org> Message-ID: On 02/13/2017 09:43 AM, JP Sugarbroad wrote: > On Mon, Feb 13, 2017, 9:08 AM Josh berkus > wrote: > > On 02/12/2017 03:57 PM, Jimmy Kaplowitz wrote: > > If the membership thinks this draft is reasonable and is willing to > > support it, I'd love to send it off to our lawyers for any wording > > tweaks from them and then vote on the output of that. > > +1, let's do this. > > > I'd vote for it. It is definitely time to get this worked through. 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. From xnox at spi-inc.org Sat Feb 25 16:46:26 2017 From: xnox at spi-inc.org (Dimitri John Ledkov) Date: Sat, 25 Feb 2017 11:46:26 -0500 Subject: 2017 update to the SPI voting algorithm for Board elections Message-ID: The board recognizes the deficiencies of the current voting algorithm utilized for Board elections as being inappropriate for multi-seat elections. After careful consideration, we recognize and acknowledge the evidence presented and we support updating the voting algorithm. Given that the voting algorithm is established via a Board resolution and given the extensive analysis undertaken by Ian Jackson, we invite Ian to draft a resolution to replace the existing Condrocet-based voting algorithm with a more appropriate algorithm, taking into account any existing feedback from spi-general, in time for the March meeting (2017-MAR-13). The Board invites members to provide commentary between the March and April board meetings. The Board intends to vote on the resolution at our April meeting (date TBD) so that we may implement it in time for the 2017 elections. Regards, Dimitri on behalf of the SPI Board of Directors On 18 July 2016 at 09:29, 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. > > 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 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.spi-inc.org > http://lists.spi-inc.org/listinfo/spi-general -- Regards, Dimitri. From jd at commandprompt.com Sat Feb 25 18:14:43 2017 From: jd at commandprompt.com (Joshua D. Drake) Date: Sat, 25 Feb 2017 10:14:43 -0800 Subject: 2017 update to the SPI voting algorithm for Board elections In-Reply-To: References: Message-ID: <7aad2032-3f00-5fae-c171-6e885707079c@commandprompt.com> On 02/25/2017 08:46 AM, Dimitri John Ledkov wrote: > Given that the voting algorithm is established via a Board resolution > and given the extensive analysis undertaken by Ian Jackson, we invite > Ian to draft a resolution to replace the existing Condrocet-based > voting algorithm with a more appropriate algorithm, taking into > account any existing feedback from spi-general, in time for the March > meeting (2017-MAR-13). This is great news. Ian, question... is there anything wrong with using what OpenSource.org uses? (https://heliosvoting.org/) 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. From ijackson at chiark.greenend.org.uk Mon Feb 27 18:09:21 2017 From: ijackson at chiark.greenend.org.uk (Ian Jackson) Date: Mon, 27 Feb 2017 18:09:21 +0000 Subject: 2017 update to the SPI voting algorithm for Board elections [and 1 more messages] In-Reply-To: <7aad2032-3f00-5fae-c171-6e885707079c@commandprompt.com>, References: <7aad2032-3f00-5fae-c171-6e885707079c@commandprompt.com> Message-ID: <22708.27473.312455.528911@chiark.greenend.org.uk> Dimitri John Ledkov writes ("2017 update to the SPI voting algorithm for Board elections"): > The board recognizes the deficiencies of the current voting algorithm > utilized for Board elections as being inappropriate for multi-seat > elections. After careful consideration, we recognize and acknowledge > the evidence presented and we support updating the voting algorithm. Thanks. > Given that the voting algorithm is established via a Board resolution > and given the extensive analysis undertaken by Ian Jackson, we invite > Ian to draft a resolution to replace the existing Condrocet-based > voting algorithm with a more appropriate algorithm, taking into > account any existing feedback from spi-general, in time for the March > meeting (2017-MAR-13). I therefore intend to draft a resolution to replace the Condorcet board voting system with the Single Transferrable Vote (STV). There are numerous variants of STV, which have minor differences. The differences only matter in edge cases, but they affect the detailed calculations at each stage. It is necessary to pick a variant. Candidate variants which have been plausibly suggested are: * The UK Electoral Reform Society's Rules for STV. This is very well-established, but it has many features which are optimised for hand-counting with paper ballots. These edge case interpretations are tiresome to program in a computer and sometimes a bit odd. * Scottish STV, as used by local government elections in Scotland. This has several advantages: - There is a clear, readable and unambiguous specification set out in public UK legislation. - There is an implementation in OpenSTV, which seems reliable (and has been around for quite some time) - As an experiment, I reimplemented the algorithm myself and found it to be tractable * Meek STV, as used by the Apache Software Foundation. In my searches I didn't manage to find a stable and widely-used implementation. I am also more comfortable with adopting a voting system choice from politically-oriented parts of civil society, or governments, than I am from software organisations. Many software organisations have a poor record of handling governance questions. I therefore intend to propose a resolution that we adopt Scottish STV. Here's a draft. WHEREAS 1. Condorcet is suitable for a single-winner voting system, but is seriously lacking in proportionality in for multi-winner voting systems, such as SPI's Board Elections. 2. The Single Transferrable Vote is a very widely-adopted proportional preferential voting system. (And may be the only such system.) 3. The Scottish STV variant is clearly specified; we have an established and stable Free Software implementation of it; and it is straightforward to (re)implement. Other STV variants appear to lack some of these good properties. 4. Ian Jackson has offered to help with the implementation of STV for SPI. THEREFORE THE SPI BOARD RESOLVES 5. Future elections to the SPI Board will be counted according to the Scottish Single Transferrable Vote. Scottish STV will also be used by SPI for any other multi-winner election. 6. Specifically, the algorithm to be used is that specified in Rules 45-52 of the Scottish Local Government Elections Order 2007 (a UK Statutory Instrument): http://www.legislation.gov.uk/ssi/2007/42/schedule/1/part/III/crossheading/counting-of-votes/made 7. We expect that the practical implementation will be by means of OpenSTV, for example the openstv package in Debian. However, any differences between the Rules in the Order, and the implementation in OpenSTV (or other software), are to be resolved in favour of the Rules. 8. The SPI Secretary is requested to liase with Ian Jackson, so that the necessary changes to SPI software and infrastructure can be identified and implemented. Joshua D. Drake writes ("Re: 2017 update to the SPI voting algorithm for Board elections"): > On 02/25/2017 08:46 AM, Dimitri John Ledkov wrote: > > Given that the voting algorithm is established via a Board resolution > > and given the extensive analysis undertaken by Ian Jackson, we invite > > Ian to draft a resolution to replace the existing Condrocet-based > > voting algorithm with a more appropriate algorithm, taking into > > account any existing feedback from spi-general, in time for the March > > meeting (2017-MAR-13). > > This is great news. Ian, question... is there anything wrong with using > what OpenSource.org uses? (https://heliosvoting.org/) That's a website. There is no documentation explaining what their system is. The hamburger in the top right didn't do anything for me (perhaps because I have JavaScript disabled). I did a bit of web searching and this seems to be some kind of novel ballot casting protocol. I don't even see any discussion of what voting system[1] they use or support. Let's fix our voting system[1] first and then think about improving our ballot casting protocol. Thanks, Ian. [1] I mean, the algorithm used to convert a pile of ballot papers into a result. Not the voting protocol. From noodles at earth.li Mon Feb 27 18:58:23 2017 From: noodles at earth.li (Jonathan McDowell) Date: Mon, 27 Feb 2017 18:58:23 +0000 Subject: 2017 update to the SPI voting algorithm for Board elections [and 1 more messages] In-Reply-To: <22708.27473.312455.528911@chiark.greenend.org.uk> References: <7aad2032-3f00-5fae-c171-6e885707079c@commandprompt.com> <22708.27473.312455.528911@chiark.greenend.org.uk> Message-ID: <20170227185823.GD16224@earth.li> On Mon, Feb 27, 2017 at 06:09:21PM +0000, Ian Jackson wrote: > Dimitri John Ledkov writes ("2017 update to the SPI voting algorithm for Board elections"): > > The board recognizes the deficiencies of the current voting algorithm > > utilized for Board elections as being inappropriate for multi-seat > > elections. After careful consideration, we recognize and acknowledge > > the evidence presented and we support updating the voting algorithm. ... > 7. We expect that the practical implementation will be by means of > OpenSTV, for example the openstv package in Debian. However, any > differences between the Rules in the Order, and the implementation > in OpenSTV (or other software), are to be resolved in favour of the > Rules. Given that we have an existing web based voting application that is written in Python it would be preferable for any new vote counting system to function within this framework. It's not clear to me that this is the case with OpenSTV, nor that it's desirable to specify the software means to achieve the desired goal as part of the board resolution. (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.) J. -- ... Where's your fishing rod, lawn ornament? From bap at debian.org Mon Feb 27 22:30:51 2017 From: bap at debian.org (Barak A. Pearlmutter) Date: Mon, 27 Feb 2017 22:30:51 +0000 Subject: 2017 update to the SPI voting algorithm for Board elections [and 1 more messages] In-Reply-To: <22708.27473.312455.528911@chiark.greenend.org.uk> References: <7aad2032-3f00-5fae-c171-6e885707079c@commandprompt.com> <22708.27473.312455.528911@chiark.greenend.org.uk> Message-ID: I am very happy to see SPI adopt a voting system designed for proportional representation. However I do feel obligated to correct a simple incorrect statement, namely that STV, a proportional representation system built upon IRV, is in some sense best-of-breed. STV in fact exhibits a variety of very serious pathologies, not just in theory but in actual practice. Even IRV itself exhibits some serious problems, including most troublingly non-monotonicity---meaning that under some not-unusual circumstances changing a ballot to rank a particular candidate *higher* can cause the candidate to go from winning to losing. STV necessarily inherits these pathologies. Although poorly formatted, the following case study of an actual election, the 2009 Burlington Vermont Mayoral election, shows that the IRV system actually used exhibited about the worst imaginable pathology: of the three major candidates, it elected the one who lost head-to-head to each of the other two according to the ballots cast. Details: http://rangevoting.org/Burlington.html Burlington subsequently changed its election system away from IRV. Similar pathologies apparently happened in the IRV 2006 Peru presidential election and the IRV 1970 Chile presidential election. Using the Debian leader election data 2001-2005, in one of those five elections IRV would have given a different winner than the Condorcet method actually used, even though in all cases the Condorcet winner beat all other candidates head-to-head. See http://rangevoting.org/Debian2003.html for details. In another one of the elections there were a variety of IRV pathologies actually exhibited. The most interesting of these to me is that there were two ballots each of which had the property that, had IRV been used, removing that ballot, which prefers A to B, would have changed the winner from B to A. I don't have a dog in this fight. I'm just interested in the math and in Bayesian methods. These have convinced me that Reweighted Range Voting (RRV, http://rangevoting.org/RRV.html) and Asset Voting are the best proportional representation voting systems currently known. And that the problems with STV are not merely academic but occur frequently in real elections. Asset Voting does not seem practical for SPI---although it would be pretty fun. STV (and even IRV) do not come off very well in any of the careful neutral analyses I've seen. --Barak. From henrik.ingo at avoinelama.fi Tue Feb 28 11:21:48 2017 From: henrik.ingo at avoinelama.fi (Henrik Ingo) Date: Tue, 28 Feb 2017 13:21:48 +0200 Subject: 2017 update to the SPI voting algorithm for Board elections [and 1 more messages] In-Reply-To: <22708.27473.312455.528911@chiark.greenend.org.uk> References: <7aad2032-3f00-5fae-c171-6e885707079c@commandprompt.com> <22708.27473.312455.528911@chiark.greenend.org.uk> Message-ID: Just wanted to share some more information on the Helios voting software: On Mon, Feb 27, 2017 at 8:09 PM, Ian Jackson wrote: > Dimitri John Ledkov writes ("2017 update to the SPI voting algorithm for Board elections"): > Joshua D. Drake writes ("Re: 2017 update to the SPI voting algorithm for Board elections"): >> This is great news. Ian, question... is there anything wrong with using >> what OpenSource.org uses? (https://heliosvoting.org/) > > That's a website. There is no documentation explaining what their > system is. The hamburger in the top right didn't do anything for me > (perhaps because I have JavaScript disabled). > > I did a bit of web searching and this seems to be some kind of novel > ballot casting protocol. I don't even see any discussion of what > voting system[1] they use or support. You would have wanted to get to this page: https://heliosvoting.org/docs Helios implements an e-voting system based on homomorphic encryption. Algorithms for secure e-voting are a field of their own in cryptography, and on a high level can be divided into 2 main categories: mix-net based and homomorphic encryption. What makes Helios interesting is that it is one of very few real world software implementations of such algorithms. As I'm sure all of you know, most voting software, whether used by governments or organizations like SPI, do not actually implement any cryptographically secure e-voting algorithm, rather just get by with using some commonly used crypto for the communication channel, such as HTTPS or PGP, or not even that. While a homomorphic e-voting algorithm is arguably better in many ways, a fundamental property of such algorithms tends to be that they can only be used to vote for N-out-of-M options. On my blog I once explored an approach to encode a preferential voting system, such as STV, into an N-out-of-M ballot. I believe that is possible for small elections such as the SPIs. But definitively it is not supported by Helios out of the box, and attempting to do it could turn out to be hacky. As some readers are likely to be interested in this topic, here are some links for further reading. My blog post contains links to actual academic articles as well. http://openlife.cc/blogs/2013/january/cryptographic-e-voting-algorithms-general In particular, this talk by the creator of Helios could be interesting: https://air.mozilla.org/wheres-my-vote/ As this is going in an off-topic direction, I suppose you can comment on my blog post if you have further questions. > Let's fix our voting system[1] first and then think about improving > our ballot casting protocol. If the current proposal is to simply change the software that counts the votes, and continue using the current system for actually casting the vote, then I agree 100%. henrik -- henrik.ingo at avoinelama.fi +358-40-5697354 skype: henrik.ingo irc: hingo www.openlife.cc My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7 From noodles at earth.li Tue Feb 28 12:07:44 2017 From: noodles at earth.li (Jonathan McDowell) Date: Tue, 28 Feb 2017 12:07:44 +0000 Subject: 2017 update to the SPI voting algorithm for Board elections In-Reply-To: <20170227185823.GD16224@earth.li> References: <7aad2032-3f00-5fae-c171-6e885707079c@commandprompt.com> <22708.27473.312455.528911@chiark.greenend.org.uk> <20170227185823.GD16224@earth.li> Message-ID: <20170228120744.GF16224@earth.li> On Mon, Feb 27, 2017 at 06:58:23PM +0000, Jonathan McDowell wrote: > On Mon, Feb 27, 2017 at 06:09:21PM +0000, Ian Jackson wrote: > > Dimitri John Ledkov writes ("2017 update to the SPI voting algorithm for Board elections"): > > > The board recognizes the deficiencies of the current voting algorithm > > > utilized for Board elections as being inappropriate for multi-seat > > > elections. After careful consideration, we recognize and acknowledge > > > the evidence presented and we support updating the voting algorithm. > ... > > 7. We expect that the practical implementation will be by means of > > OpenSTV, for example the openstv package in Debian. However, any > > differences between the Rules in the Order, and the implementation > > in OpenSTV (or other software), are to be resolved in favour of the > > Rules. > > Given that we have an existing web based voting application that is > written in Python it would be preferable for any new vote counting > system to function within this framework. It's not clear to me that this > is the case with OpenSTV, nor that it's desirable to specify the > software means to achieve the desired goal as part of the board > resolution. 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. 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 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. J. -- ... Why are we here? Because we're here. Roll the bones. From ijackson at chiark.greenend.org.uk Tue Feb 28 15:32:11 2017 From: ijackson at chiark.greenend.org.uk (Ian Jackson) Date: Tue, 28 Feb 2017 15:32:11 +0000 Subject: 2017 update to the SPI voting algorithm for Board elections [and 1 more messages] [and 1 more messages] In-Reply-To: <20170227185823.GD16224@earth.li>, <20170228120744.GF16224@earth.li> References: <7aad2032-3f00-5fae-c171-6e885707079c@commandprompt.com> <22708.27473.312455.528911@chiark.greenend.org.uk> <20170227185823.GD16224@earth.li> <20170228120744.GF16224@earth.li> Message-ID: <22709.38907.540202.197141@chiark.greenend.org.uk> 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 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. From xnox at spi-inc.org Tue Feb 28 15:33:18 2017 From: xnox at spi-inc.org (Dimitri John Ledkov) Date: Tue, 28 Feb 2017 15:33:18 +0000 Subject: 2017 update to the SPI voting algorithm for Board elections [and 1 more messages] In-Reply-To: References: <7aad2032-3f00-5fae-c171-6e885707079c@commandprompt.com> <22708.27473.312455.528911@chiark.greenend.org.uk> Message-ID: On 27 February 2017 at 22:30, Barak A. Pearlmutter wrote: > I am very happy to see SPI adopt a voting system designed for > proportional representation. > > However I do feel obligated to correct a simple incorrect statement, > namely that STV, a proportional representation system built upon IRV, > is in some sense best-of-breed. STV in fact exhibits a variety of very > serious pathologies, not just in theory but in actual practice. Even > IRV itself exhibits some serious problems, including most troublingly > non-monotonicity---meaning that under some not-unusual circumstances > changing a ballot to rank a particular candidate *higher* can cause > the candidate to go from winning to losing. STV necessarily inherits > these pathologies. > > Although poorly formatted, the following case study of an actual > election, the 2009 Burlington Vermont Mayoral election, shows that the > IRV system actually used exhibited about the worst imaginable > pathology: of the three major candidates, it elected the one who lost > head-to-head to each of the other two according to the ballots cast. > > Details: http://rangevoting.org/Burlington.html > > Burlington subsequently changed its election system away from IRV. > > Similar pathologies apparently happened in the IRV 2006 Peru > presidential election and the IRV 1970 Chile presidential election. > > Using the Debian leader election data 2001-2005, in one of those five > elections IRV would have given a different winner than the Condorcet > method actually used, even though in all cases the Condorcet winner > beat all other candidates head-to-head. See > http://rangevoting.org/Debian2003.html for details. In another one of > the elections there were a variety of IRV pathologies actually > exhibited. The most interesting of these to me is that there were two > ballots each of which had the property that, had IRV been used, > removing that ballot, which prefers A to B, would have changed the > winner from B to A. > > I don't have a dog in this fight. I'm just interested in the math and > in Bayesian methods. These have convinced me that Reweighted Range > Voting (RRV, http://rangevoting.org/RRV.html) and Asset Voting are the > best proportional representation voting systems currently known. And > that the problems with STV are not merely academic but occur > frequently in real elections. Asset Voting does not seem practical for > SPI---although it would be pretty fun. STV (and even IRV) do not come > off very well in any of the careful neutral analyses I've seen. > > --Barak. My personal impression about this is that irrespective of the voting system used, there will always be anomalies. And the proposal here is to change one set of quirks for another. Note that unlike the DPL / Mayoral elections we are striving to elect 3 directors for a three-year term every year, such that the board has continuity and is thus staggered. So far I have also been impressed with the quality of candidates, and (semi-jokingly), I could even be in favor of using urandom() algorithm to pick winners. If the proposed algorithm picks an underdog as one of the directors I would be fine with that, since that adds entropy to the election results which imho is exciting and fun =) ps. I might actually use urandom() next time I need to cast a ballot -- Regards, Dimitri. From ijackson at chiark.greenend.org.uk Tue Feb 28 15:56:27 2017 From: ijackson at chiark.greenend.org.uk (Ian Jackson) Date: Tue, 28 Feb 2017 15:56:27 +0000 Subject: 2017 update to the SPI voting algorithm for Board elections [and 1 more messages] [and 1 more messages] In-Reply-To: , References: <7aad2032-3f00-5fae-c171-6e885707079c@commandprompt.com> <22708.27473.312455.528911@chiark.greenend.org.uk> Message-ID: <22709.40363.149227.459226@chiark.greenend.org.uk> Henrik Ingo writes ("Re: 2017 update to the SPI voting algorithm for Board elections [and 1 more messages]"): > Just wanted to share some more information on the Helios voting software: Thanks. > While a homomorphic e-voting algorithm is arguably better in many > ways, a fundamental property of such algorithms tends to be that they > can only be used to vote for N-out-of-M options. I see. Thanks. That wasn't clear from the docs. > > Let's fix our voting system[1] first and then think about improving > > our ballot casting protocol. > > If the current proposal is to simply change the software that counts > the votes, and continue using the current system for actually casting > the vote, then I agree 100%. Yes, that is the current proposal. Thanks. Barak A. Pearlmutter writes ("Re: 2017 update to the SPI voting algorithm for Board elections [and 1 more messages]"): > However I do feel obligated to correct a simple incorrect statement, > namely that STV, a proportional representation system built upon > IRV, is in some sense best-of-breed. I'm sorry if this is going to sound tetchy, but we have had this discussion ad infinitum. As I say in the draft resolution: 2. The Single Transferrable Vote is a very widely-adopted proportional preferential voting system. (And may be the only such system.) I think this is not quite as precise and therefore not as strong as it should be. I think I should replace it with something like this: 2. There are very few widely-adopted proportional voting systems. The Single Transferrable Vote is the only one which is suitable SPI's Board elections. All the others depend on the existence of parties. It's not the case that I am saying STV is "best of breed". STV is _the only serious candidate_ (given that AMS, party lists, and so on, are plainly unsuitable). I find your continuing advocacy of RRV incomprehensible, particularly after we had that very long exchange of emails in August. RRV is not an established voting system. Almost no-one else is using it. Civil society bodies, interested in general voting reform for public elections, support STV. Furtherrmore, range voting, of which RRV is a variant, has the critical flaw that it encourages naive voters to cast ineffective ballots. Finally, SPI should not be in the business of voting system innovation. Nor should SPI be in the business of doing our own detailed analysis of voting systems, as you are doing. We should leave voting system development, analysis, and recommendation, to civil society organisations specialising in voting reform, such as Fair Votes Canada and the UK Electoral Reform Society. I explained all of this first on list, and then at length in private email to you. In any case, the SPI Board have asked me to draft a resolution. Implicitly, the Board have therefore experessed an intention to endorse my recommendation of STV. I am going to proceed on that basis. Thanks, Ian. From jd at commandprompt.com Tue Feb 28 17:29:52 2017 From: jd at commandprompt.com (Joshua D. Drake) Date: Tue, 28 Feb 2017 09:29:52 -0800 Subject: 2017 update to the SPI voting algorithm for Board elections [and 1 more messages] [and 1 more messages] In-Reply-To: <22709.40363.149227.459226@chiark.greenend.org.uk> References: <7aad2032-3f00-5fae-c171-6e885707079c@commandprompt.com> <22708.27473.312455.528911@chiark.greenend.org.uk> <22709.40363.149227.459226@chiark.greenend.org.uk> Message-ID: <52d42d62-bda9-f37e-4594-5fc46d5b64b2@commandprompt.com> On 02/28/2017 07:56 AM, Ian Jackson wrote: > Henrik Ingo writes ("Re: 2017 update to the SPI voting algorithm for Board elections [and 1 more messages]"): > Finally, SPI should not be in the business of voting system > innovation. Nor should SPI be in the business of doing our own > detailed analysis of voting systems, as you are doing. We should > leave voting system development, analysis, and recommendation, to > civil society organisations specialising in voting reform, such as > Fair Votes Canada and the UK Electoral Reform Society. > 1 Billion times this. 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. From henrik.ingo at avoinelama.fi Tue Feb 28 17:38:34 2017 From: henrik.ingo at avoinelama.fi (Henrik Ingo) Date: Tue, 28 Feb 2017 19:38:34 +0200 Subject: 2017 update to the SPI voting algorithm for Board elections [and 1 more messages] [and 1 more messages] In-Reply-To: <52d42d62-bda9-f37e-4594-5fc46d5b64b2@commandprompt.com> References: <7aad2032-3f00-5fae-c171-6e885707079c@commandprompt.com> <22708.27473.312455.528911@chiark.greenend.org.uk> <22709.40363.149227.459226@chiark.greenend.org.uk> <52d42d62-bda9-f37e-4594-5fc46d5b64b2@commandprompt.com> Message-ID: On Tue, Feb 28, 2017 at 7:29 PM, Joshua D. Drake wrote: > On 02/28/2017 07:56 AM, Ian Jackson wrote: >> >> Henrik Ingo writes ("Re: 2017 update to the SPI voting algorithm for Board >> elections [and 1 more messages]"): > > >> Finally, SPI should not be in the business of voting system >> innovation. Nor should SPI be in the business of doing our own >> detailed analysis of voting systems, as you are doing. We should >> leave voting system development, analysis, and recommendation, to >> civil society organisations specialising in voting reform, such as >> Fair Votes Canada and the UK Electoral Reform Society. >> > > 1 Billion times this. > I don't know whether you intended it that way, but in Ian's original message, this was not a reply to anything I wrote. henrik -- henrik.ingo at avoinelama.fi +358-40-5697354 skype: henrik.ingo irc: hingo www.openlife.cc My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7 From jd at commandprompt.com Tue Feb 28 17:57:40 2017 From: jd at commandprompt.com (Joshua D. Drake) Date: Tue, 28 Feb 2017 09:57:40 -0800 Subject: 2017 update to the SPI voting algorithm for Board elections [and 1 more messages] [and 1 more messages] In-Reply-To: References: <7aad2032-3f00-5fae-c171-6e885707079c@commandprompt.com> <22708.27473.312455.528911@chiark.greenend.org.uk> <22709.40363.149227.459226@chiark.greenend.org.uk> <52d42d62-bda9-f37e-4594-5fc46d5b64b2@commandprompt.com> Message-ID: <3f06b2c8-d001-81b6-92b5-53f3268c7f90@commandprompt.com> On 02/28/2017 09:38 AM, Henrik Ingo wrote: > On Tue, Feb 28, 2017 at 7:29 PM, Joshua D. Drake wrote: >> On 02/28/2017 07:56 AM, Ian Jackson wrote: >>> >>> Henrik Ingo writes ("Re: 2017 update to the SPI voting algorithm for Board >>> elections [and 1 more messages]"): >> >> >>> Finally, SPI should not be in the business of voting system >>> innovation. Nor should SPI be in the business of doing our own >>> detailed analysis of voting systems, as you are doing. We should >>> leave voting system development, analysis, and recommendation, to >>> civil society organisations specialising in voting reform, such as >>> Fair Votes Canada and the UK Electoral Reform Society. >>> >> >> 1 Billion times this. >> > > I don't know whether you intended it that way, but in Ian's original > message, this was not a reply to anything I wrote. Henrik, My response was the affirm Ian's point that is all. Specifically: * SPI should not be in the business of voting system innovation. * We should leave voting system development, analysis, and recommendation, to civil society organisations specialising in voting reform, such as Fair Votes Canada and the UK Electoral Reform Society. 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.