Re: [rtcweb] The Voting Process

John Leslie <john@jlc.net> Thu, 28 November 2013 13:53 UTC

Return-Path: <john@jlc.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C886F1AD8D5 for <rtcweb@ietfa.amsl.com>; Thu, 28 Nov 2013 05:53:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R28rYWfIxsWB for <rtcweb@ietfa.amsl.com>; Thu, 28 Nov 2013 05:53:13 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id C264E1ACC81 for <rtcweb@ietf.org>; Thu, 28 Nov 2013 05:53:12 -0800 (PST)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 617DEC94C0; Thu, 28 Nov 2013 08:53:10 -0500 (EST)
Date: Thu, 28 Nov 2013 08:53:10 -0500
From: John Leslie <john@jlc.net>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <20131128135310.GE87911@verdi>
References: <52935C89.5040408@ericsson.com> <CAGgHUiQnkQKkc-ptMu6DtfUYJY6N9i7PUaeAqKxp96nB2MQBGA@mail.gmail.com> <52936207.5040704@ericsson.com> <E44893DD4E290745BB608EB23FDDB7620A13302B@008-AM1MPN1-041.mgdnok.nokia.com> <5295B273.1060305@ericsson.com> <C5B67CF6-44C2-44ED-A087-67D9737870AD@gmail.com> <5295F718.9010603@ericsson.com> <20131127175414.GA87911@verdi> <52971935.50408@ericsson.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <52971935.50408@ericsson.com>
User-Agent: Mutt/1.4.1i
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] The Voting Process
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Nov 2013 13:53:16 -0000

Note: I'm not trying to be contentious here; I'm merely offering my
expertise on voting. I have supervised Hale Preferential Transferrable
Voting, and have served as Assistant Moderator during Town voting.

Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
> On 2013-11-27 18:54, John Leslie wrote:
>> Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
>> 
>> A reference to wikipedia is completely unstable unless it refers
>> to the webpage retrieved at a particular time.
> 
> Yes, we will update our proposal to reference a particular date. The one
> currently available.

   :^)

   (May I suggest picking a particular time available from The Wayback
Machine?)

>> What follows doesn't do that. It instead establishes rules for
>> determining at some later time _whether_ an individual is eligible.
> 
> Yes, and the reason is that we realized what amount of work it would be
> to gather a list of all that would be eligible in an list and publish
> that ahead of time.

   Agreed.

   Usually there is a registration process where potential voters declare
an intent to vote, and their eligibility is verified and published.

>> Obviously missing from this list is persons subscribed to the
>> mailing-list during some period. Those would ordinarily be considered
>> participants.
> 
> Still our proposal in the updated version will be participants that
> considered active in the WG. Thus the ones that been to a meeting, IRL
> or electronically in the jabber room, or have sent an email to the list.

   "Sent an email to the list" may prove subject to argument. Many folks
use and abandon multiple email addresses. Also, I frequently see "On
behalf of <name>" emails...

>> "Voter" is vague here. I take it to mean any person sending a ballot.
> 
> Yes, the balloting individual.

   Thanks.

>> Thus there is no way of challenging a right to vote before the
>> ballot itself is opened. I believe that is unheard-of.
> 
> The point was to have clear cut criteria for who are eligible.

   Someone must evaluate against those criteria. This, IMHO, should
be done in plain view.

>> It is, IMHO, strange to have no list of eligible voters to enable
>> challenging eligibility (or absence from the list) before a vote is
>> cast.
> 
> You as an individual can already now verify that you can provide such a
> pointer or not.

   Someone must evaluate any pointer I provide. This, IMHO, should
be done in plain view.

> I agree that it is not possible to challenge another persons eligibility
> prior to the balloting having completed and the list of who voted
> becomes available.

   :^(

>> This is very unusual in Instant Runoff. There are always choices
>> that a voter would vote _against_ regardless of the alternatives.
>> This requires that a voter may be counted as in favor of something
>> s/he completely opposes.
> 
> My understanding this was one of the few options in Instant Runoff
> voting.

   (There are quite a few options during counting...)

> We have selected full ranked to ensure that the voting will provide
> a winner. If one doesn't mark all the option then that can't be
> guaranteed. We wanted a voting process that would yield a winner.

   This is a misunderstanding.

   All versions can guarantee a winner. None of them can avoid the
need for tie-breaking.

   It is my understanding that Australians use mandatory marking,
apparently to increase the apparent vote totals. It doesn't work IMHO,
because folks cast intentionally invalid ballots.

> I would note that No MTI at least can be used to indicate the options
> that the balloter considered better or worse than no MTI. Although
> nothing in the IVR process prevents the ranking below "no MTI" to be
> used to determine the outcome of the voting.

   Noted.

>> (Further, it leaves open the "or else" question: what happens if
>> a ballot doesn't exactly match that requirement?)
> 
> Then we propose the ballot will be discarded. The vote collector if he
> notice the issue when ballot is submitted shall contact the balloting
> individual and notify them of the issue. If not corrected ballot is
> available by end of balloting period then it will be discarded.

   This appears to say it is up to the vote collector to "notice" the
discrepancy. There is also the possibility that the discrepancy will
be found during counting...

>> Thus every detail of preference becomes public. Inevitably there will
>> be some persons who are nervous about publishing so much detail. (I
>> don't mean to imply that employers _would_ punish employees, merely
>> that employees could understandably be nervous.)
> 
> Yes, we understand that as a potential issue. However, without making
> the ballots public we don't see how we reasonably can ensure the voting
> is done correctly and in a verifiable way.

   The usual practice is to fully verify the voter before the actual
ballot is visible; then count the ballot (or declare it invalid or blank).
Votes-needed-to-win is determined after subtracting invalid and blank
counts.

>> Further, some person needs to be designated to interpret the rules
>> during counting.
> 
> Noted, we chairs propose the vote collector will be arbiter. And the
> normal IETF venues of appeal will be available for the arbiter's decision.

   Thank you.

--
John Leslie <john@jlc.net>