[rtcweb] Voting method choice (Re: Proposed Video Selection Process)

Harald Alvestrand <harald@alvestrand.no> Thu, 21 November 2013 19:12 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 18C791AE262 for <rtcweb@ietfa.amsl.com>; Thu, 21 Nov 2013 11:12:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.425
X-Spam-Status: No, score=-7.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id JP7wbDn29s5k for <rtcweb@ietfa.amsl.com>; Thu, 21 Nov 2013 11:12:37 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no []) by ietfa.amsl.com (Postfix) with ESMTP id 928E71AE072 for <rtcweb@ietf.org>; Thu, 21 Nov 2013 11:12:36 -0800 (PST)
Received: from localhost (localhost []) by eikenes.alvestrand.no (Postfix) with ESMTP id 30E0A39EAAF for <rtcweb@ietf.org>; Thu, 21 Nov 2013 20:12:00 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([]) by localhost (eikenes.alvestrand.no []) (amavisd-new, port 10024) with ESMTP id 6IIUt2lnYtX1 for <rtcweb@ietf.org>; Thu, 21 Nov 2013 20:11:53 +0100 (CET)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 4F6C339E197 for <rtcweb@ietf.org>; Thu, 21 Nov 2013 20:11:53 +0100 (CET)
Message-ID: <528E5AF7.5080403@alvestrand.no>
Date: Thu, 21 Nov 2013 20:11:51 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <528E39F4.4010706@ericsson.com>
In-Reply-To: <528E39F4.4010706@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [rtcweb] Voting method choice (Re: Proposed Video Selection 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, 21 Nov 2013 19:12:40 -0000

Forking this thread, and leaving aside all consideration of whether the 
IETF should do voting, whether the electorate is the right electorate 
for the decision and so on:

I wonder if Instant Runoff is the right choice for this situation.
Instant Runoff means that when you don't get a majority for anything, 
you drop the lowest-ranked candidate and distribute the ballots that had 
this as their #1 across the other candidates.

This has the property that in a polarized situation, compromises may get 
dropped out of the running before the alternatives that they might serve 
as a compromise between.

In this case, I'd favour a Condorcet-compatible method, such as Schulze; 
it provides the guarantee that if a choice is preferred by a majority of 
the participants over every other choice, it will always be chosen.


On 11/21/2013 05:51 PM, Magnus Westerlund wrote:
> WG,
> The WebRTC ecosystem needs to avoid interoperability failure to grow
> optimally.  The RTCWEB working group took on the task of establish Audio
> and Video MTI codecs as part of meeting that need. We have not succeeded
> in finishing that task for video using normal IETF process, but it is
> still important.
> We (WG chairs) are proposing that the working group consent to a method
> that will establish an MTI, even if the MTI chosen does not have rough
> consensus.  We would far prefer the normal IETF process, but it is not
> proving workable for this selection.
> We initially proposed a method from RFC 3929 (external review team), but
> now believe that the working group would not consent to that method.
> Instead we are proposing a method that leaves the decision in the hands
> of the WG.
> google.com
> The method we propose is based on Instant-runoff voting,
> http://en.wikipedia.org/wiki/Instant-runoff_voting, with the
> understanding that the choice will be the winner according to the
> Instant-runoff voting process.
> The steps in the proposed process are these (1-5):
> 1) Establish a final list of alternatives, based on the WG's input to
> Gonzalo's email on the 13th of November that requires any additions to
> provided by end of the 27th of November.
> 2) Establish those eligible to vote.  Any participant in the
> working group process either electronically or in-person as of yesterday
> (20th of November). Who has participated in the Working group process
> will be anyone that can be identified from:
>   - The Blue Sheets for any RTCWEB WG session during an IETF meeting or
>     an interim meeting since the WG's creation.
>   - posting of at least one email to the RTCWEB mailing list
> The voter must at time of voting prove their eligibility, by pointing to
> the mail archive or a particular blue sheet/meeting. Please verify your
> own eligibility.
> 3) Start the the voting period. Those eligible and willing to vote send
> their ballot to a vote collector (Matt Lepinski, former Nomcom chair)
> within two weeks using email. The vote collector will check when
> receiving a ballot the that the voter is eligible and send a
> confirmation email on receiving the ballot. During the balloting period
> the vote collector will keep all ballots secret.
> Balloting:
>   - The voter MUST rank ALL alternatives in their ballot from the most
>     preferred, marked with rank 1, the second most with 2, all the way
>     to the least preferred marked with rank N.
> 4) When the voting period is over the ballot collector will publish the
> results as well as all ballots, including the voters name to the RTCWEB
> WG mailing list. This enables all voting individuals to verify that
> their ballot is unmodified. And allows anyone to verify the result of
> the vote.
> 5) The selection is recorded in the drafts.
> --- End of Process Proposal ---
> This message initiates the first step in the working group consensus
> call process. Namely a one week comment and discussion period for the
> above process.
> After that week the WG chairs will update, if necessary, the proposal.
> Then using the normal IETF process in which anyone is eligible to
> participate, the chairs will ask for (rough) consensus to adopt this
> extraordinary process to achieve the working group's stated goals.  The
> end date for this consensus call is 2-weeks after the announcement of
> the consensus call.
> If the working group does not consent to using this extraordinary
> process, we will hold a consensus call if the WG can accept
> "WebRTC entities MUST support at least one of H.264 or VP8.".
> If there is failure to establish consensus even for this statement, the
> chairs conclude that the WG can't establish what to say about a MTI
> video codec.
> The WG Chairs
> Magnus Westerlund
> Cullen Jennings
> Ted Hardie
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb