Revised ANN: re: Complementary PEP308 Ternary VOTE

[Norman Petry]

Revised ANN: re: Complementary PEP308 Ternary VOTE

What follows is a message that I originally posted to comp.lang.python
on March 2nd, shortly after Raymond Hettinger's announcement of an
official vote for PEP308.

Unfortunately, the message disappeared somehow (perhaps it was cancelled
due to length?) before it reached the mailing list.  I know at least
some people on Usenet must have received the first announcement, but
perhaps not many.  Therefore, I have revised the original article for
clarity, and removed some material that is no longer relevant
(nomination period details, etc.).

I've posted this message to the mailing list, rather than Usenet, in the
hope that _this_ message will stick; it contains some important
background information about the unofficial, COMPLEMENTARY PEP308 VOTE. 
The ballot for this supplemental vote was sent to the list yesterday
(see "ANN: Ballot for Complementary PEP308 Ternary VOTE", 04 Mar 2003
17:55:48 -0600).

**********


Last Sunday, Raymond Hettinger announced that an official vote on PEP308
would be taking place between March 2nd and March 9th (see: "Vote on PEP
308:  Ternary Operator", 2 Mar 2003 02:27:15 -0800 for details).

Later that afternoon, he wrote:

>>Someone
>> else was claiming that they were going to be holding the vote up tp
this
>> point.
> 
> That person sufferred much negativity here and no longer has the time
> or inclination, so he passed the torch to me.  Hopefully, I'll be
treated
> better.  I'm volunteering the time to tally the results and then Guido
> will make the call.

It is regrettable that Aahz did not announce his intention not to
proceed with a vote on PEP308, as I would have welcomed the opportunity
to volunteer to run the "official" vote on behalf of comp.lang.python. 
Had I known about this decision, I would have spoken up sooner. 
Becoming frustrated with the lack of an official vote announcement, I
began to plan an "unofficial" vote myself, and had spent several hours
preparing it before receiving Raymond's announcement earlier today.

After receiving the official announcement, I had to decide whether or
not to proceed with my "unofficial" vote, or abandon it.  After looking
over Raymond Hettinger's plan, I decided that there would still be some
value to be gained by offering my own, supplemental vote, as the two
plans use very different types of ballots:

1) The "official" ballot allows a limited ranking of (3) choices, rather
than a full ranking to be expressed.  
2) The official ballot tries to gather "approval" information about each
choice.
3) The official ballot has an educational component, in that voters must
create specified examples in their preferred syntax.
4) My vote uses a brief nomination period to add options, whereas the
official ballot allows for write-ins
5) My vote specifies a method of aggregating preferences to determine a
winner, whereas in the official vote, the method that will be used is
unstated.
6) Slightly different sets of proposals are offered.

All of these factors may greatly affect the outcome.  Therefore, it
seemed to me that there would still be value in presenting my own,
UNOFFICIAL vote proposal to comp.lang.python, in case anyone is
interested in participating using this alternate approach.

One of my motivations for leading a vote of my own, was to ensure that a
high-quality result would be produced.  Without knowing what aggregation
method will be used, I am uncertain as to whether the official vote will
yield one.  The form of the official ballot suggests that some type of
Approval/Ranked voting hybrid is being used.  Unlike Condorcet, ordinary
Approval Voting REQUIRES the use of strategy to maximize the
effectiveness of one's ballot.  It is difficult for me to know how to
choose where to "draw the line" between acceptable and unacceptable
alternatives, without knowing the specifics of how my ballot will be
counted.  I personally DO care about the outcome of PEP308, so this
matters to me.

Another motivation for me in arranging this vote was the desire to be
able to demonstrate the effectiveness of a particular method of voting,
while at the same time contributing to the solution of a real problem. 
There have been between 25 and 50 unique proposals for adding a ternary
to Python, and several hundred arguments presented advocating different
solutions.  This makes it very difficult to find a reliable way of
determining the opinion of the community of users who must choose ONE of
these options.  Very few people are aware of Condorcet's method of
voting, yet it is ideal as a means of finding the best option from even
a very large number of alternatives.  The vote I am offering should
still be able to demonstrate this (even though it is not the official
one) and I hope that it leads to wider adoption of the method.

Please understand that I regard this vote of mine as a COMPLEMENT,
rather than a substitute for the one being organised by Raymond
Hettinger.  His vote uses a very different type of ballot, and will
therefore capture different information than mine.  Therefore both sets
of results, when viewed together, should be more useful to the BDFL than
either one would be alone.

I have no wish to undermine the official vote by drawing away
participants from it.  It may be that GvR will only consider the results
of the official vote anyway.  Therefore, PLEASE make a point of voting
in Raymond Hettinger's vote, regardless of whether or not you decide to
also participate in mine.

Please read on for additional information about this complementary vote.


**********

After careful consideration, I have decided to personally organize an
UNOFFICIAL vote on the various proposals to provide a ternary operator
for Python (PEP 308).  Details regarding nomination and voting
procedures, and the justification for holding this vote are provided
below.

Any interested person may participate in this vote.


TIMETABLE

1. Nominations - 48 HOUR (2 day) Nomination Period, which ENDED with the
publication of the ballot, on 04 Mar 2003 17:56:18 -0600.  

2. Voting - Once the nominations period had passed, a BALLOT was posted
on comp.lang.python and comp.lang.python.announce ("ANN: Ballot for
Complementary PEP308 Ternary VOTE").  This posting began a 96 HOUR (4
day) voting period, during which email ballots may be submitted.

3. Tallying - When the voting period expires, a notice will be posted to
the Python newsgroups.  This will mark the start of a tallying period
that should last not more than 24 HOURS.

4. Results - The results of the vote will be published as soon as
tallying is complete, but NOT before the voting period of the "official"
vote has ended (12 Noon EST, Sunday, March 9).  They will be posted to
comp.lang.python and comp.lang.python.announce, as well as being sent
directly to Guido van Rossum.

These time periods, expressed as weekdays for the period of March 3-9,
2003 are roughly:

Nominations:        MONDAY - TUESDAY
Voting:             WEDNESDAY - SATURDAY
Tallying & Results: SUNDAY (9 MARCH)

(may not be accurate, depending on where you live in the world)


MY QUALIFICATIONS

I realise that many c.l.p. particpants may have doubts about my
qualifications for organising this vote.  For one thing, although I do
use Python regularly in my own work, I am not a recognised member of the
Python community -- this is only the 3rd message I have ever posted to
comp.lang.python!  Also, I do not pretend to be impartial with regard to
the outcome of PEP 308 -- in my two previous postings to the newsgroup I
stated my preferences quite clearly.

The reasons why I feel qualified to lead this process are:

1) I have a personal interest in social choice theory, and have studied
voting systems for the past several years so I am quite familiar with a
range of single-winner methods that are appropriate for this type of
vote.  I have been a long-time participant on the Election Methods
mailing list (http://www.eskimo.com/~robla/em/) which discusses these
issues.  As part of that involvement, I have carried out simulations of
a variety of voting methods using software I wrote in Python. 
Therefore, I have already implemented the algorithms needed to do
election tallies using variants of Condorcet's method, etc.

2) For a few months in 2000/2001 I chaired a joint committee of members
of the Debian Project (http://www.debian.org) and the Election Methods
list, looking at ways of improving their voting method and processes
(see
http://lists.debian.org/debian-vote/2000/debian-vote-200012/msg00091.html for an introduction).  During that committee work, I arranged several email votes on particular issues, using the same voting method that I plan to use here.  I therefore have some experience doing this type of thing, as well as the tools (reporting software, etc.) needed to produce results for comp.lang.python.

3) While I hope that you will trust me to carry out the vote fairly, I
do not expect you to rely on my assurances.  The published results of
the vote will include sufficient information to allow anyone to verify
them independently (see below for details).


NOMINATIONS

(deleted, as the details are no longer relevant)


VOTING

When a single selection must be made from among a large number of
alternatives, a high-quality single-winner voting method must be used to
produce meaningful results.  Therefore, a variant of CONDORCET'S METHOD
that is sometimes referred to as "Cloneproof SSD" will be used for this
vote.  A brief description of this method can be found here:
http://www.electionmethods.org/CondorcetEx.htm  In this system, a RANKED
BALLOT is used to collect preferences from voters.

There will be NO multi-stage process for either reducing the number of
initial choices, or for deciding separately whether to adopt the ternary
in principle, and leave the question of syntax to a later vote. 
Condorcet's method doesn't suffer a loss of accuracy when there are a
large number of alternatives, and multi-stage processes are both
needlessly complicated and time-consuming for participants.  They also
tend to bias the outcome in favour of particular alternatives and lead
to certain types of strategic/insincere voting.  

There will also be NO supermajority requirements of any kind, both
because they are undemocratic (effectively giving the supporters of
certain options multiple votes), and because they are unnecessary.  When
the results are published, the BDFL can easily decide for himself what
sort of supermajority (if any) he requires to decide that a particular
syntax proposal has sufficient support to make the addition of the
ternary to Python worthwhile.  Pairwise voting methods like Cloneproof
SSD make this sort of determination easy, since the relative support for
every possible pair of options is published with the results.


RESULTS OF THE VOTE

Once tallying is complete, the results of the vote will be published on
March 9th (NOT before the voting period of the "official" vote has
ended), and will include the following items:

1. A LIST of the BALLOTS that were received, with each entry consisting
of the voter's NAME, their EMAIL ADDRESS, and their COMPLETED BALLOT. 
Note from this that the vote is using an OPEN BALLOT, NOT A SECRET
BALLOT.  This is necessary to allow participants to verify their own
ballot in the results, as well as make ballot-stuffing by unrecognised
individuals more difficult (see item 5, below for additional uses). 
Therefore, if you do not want any or all of this information about you
made public, DO NOT VOTE!  I will munge the published email addresses a
bit to try to counter the harmful effects of spambots, but you may wish
to use a throwaway email account if you are concerned about this.

2. A human-readable version of the PAIRWISE MATRIX, which is a type of
intermediate result that is used to determine the winner in pairwise
voting methods.  It provides a kind of summary that is very useful for
interpreting the results of the election, and assessing the strength of
support for each option.  An example of this type of thing can be seen
here: http://www.debian.org/vote/howto_result

3. A calculation of the SINGLE WINNER, as determined by the tallying
rules of the "Cloneproof SSD" variant of Condorcet's Method
(http://www.electionmethods.org/CondorcetEx.htm).

4. A calculation of the SOCIAL RANKING of the options, using a tallying
method sometimes known as "Ranked Pairs(wv)", or "Tideman's
Method(wv)".  The social ranking is useful, because in addition to
identifying the single winner (1st rank), it also orders the remaining
options based on the strength of their support.  This will allow the
BDFL to easily identify other well-liked alternatives, if he does not
wish to implement the SINGLE WINNER.

5. GPL-licensed Python source code that can be used by anyone to verify
the algorithms and/or the published results.  This code may be
immediately useful to the BDFL, as he may wish to use only a subset of
the published ballots (people whose opinion he trusts, for example), and
determine the winner based on those votes alone.  Also, if additional
votes from other communities of Python programmers are received after
March 9th, they could easily be added to the published ballots to
determine a revised result.


FINAL NOTE

Although I will attempt to answer questions about the voting process
described here, I will NOT participate in any debate on this topic, nor
will I consider changes to the timetable or process described above.  

Participation in this vote is optional and the results are only
advisory, so if you find the process or voting method objectionable the
simplest solution is to not participate.  Those who favour other methods
of voting that depend on ranked ballots (STV/IRV, Borda, etc.) will have
access to the raw ballot data once voting is complete, and are welcome
to generate and publish their own results using their preferred
method(s).

While the topic of voting systems is of interest to me, I haven't the
time to discuss it this week.  There are quite literally an infinite
number of possible ways to aggregate voter preferences, so such
discussions can take a lot of time!  Furthermore, I do not consider
comp.lang.python to be an appropriate forum for this type of
discussion.  Based on my experience and previous research, I have
selected what I consider to be the best available methods to gather
voter opinions and arrive at an optimal social choice.  It is unlikely
that any discussion that might take place here would persuade me
otherwise.

For those interested in the subject of voting, I recommend that you
begin by reviewing the materials at:

http://www.electionmethods.org/

Should you then wish to do further research, the archives of the
Election Methods mailing list contains a great deal of useful
information (and a lot of junk).  It is available in various formats at
this location:

http://www.eskimo.com/~robla/em/

If you wish to participate in ongoing discussions of voting systems
theory, the Election Methods list itself is highly recommended. 
Instructions for subscribing are available at the above link.

--
Norman Petry