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

Harald Alvestrand <harald@alvestrand.no> Sun, 24 November 2013 16:53 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D021ADFD0 for <rtcweb@ietfa.amsl.com>; Sun, 24 Nov 2013 08:53:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.425
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y68tFX5urtUd for <rtcweb@ietfa.amsl.com>; Sun, 24 Nov 2013 08:53:15 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3181ADFCB for <rtcweb@ietf.org>; Sun, 24 Nov 2013 08:53:15 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2B99539E09F for <rtcweb@ietf.org>; Sun, 24 Nov 2013 17:52:38 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DVKTX2IhjD1 for <rtcweb@ietf.org>; Sun, 24 Nov 2013 17:52:37 +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 1F41439E070 for <rtcweb@ietf.org>; Sun, 24 Nov 2013 17:52:37 +0100 (CET)
Message-ID: <52922ED3.7070908@alvestrand.no>
Date: Sun, 24 Nov 2013 17:52:35 +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> <528E5AF7.5080403@alvestrand.no>
In-Reply-To: <528E5AF7.5080403@alvestrand.no>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [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: Sun, 24 Nov 2013 16:53:17 -0000

On 11/21/2013 08:11 PM, Harald Alvestrand wrote:
> 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.
>
> http://en.wikipedia.org/wiki/Condorcet_method#Schulze_method

I haven't seen much response to this - except pointing out that no 
voting method is perfect - but I really think the issue of Condorcet vs 
IRV matters in this case.

We have two strong camps who have a clear preferred choice, and we have 
some possible compromises. Me being the compromising type, I think we 
might be better off with a compromise than one of the strong camps' 
preferences.

Let's imagine, for a moment, that the options are:

A: Codec A
B: Codec B
C: At least one of Codec A and B

If the distribution is like this:

A proponents (40%): A C B
B proponents (40%): B C A
Compromisers group 1 (5%): C A B
Compromisers group 2 (15%): C B A

Then under IRV, the first round will go 40/40/20, alternative C will be 
eliminated, and B will be chosen.
Under Condorcet, the outcomes will be:

- A outranks B on 55%
- C outranks A on 60%
- C outranks B on 60%

Therefore, C is a Condorcet winner.

IRV is less likely to lead to a second-ranked compromise that everyone 
can live with than Condorcet.