Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90625
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.27 cause and error)
To: internals@lists.php.net
References: <373698cabe053cb9bec8e1f6dc969906@mail.gmail.com>
 <BY2PR02MB298CD3F862A71149FB29857ACCB0@BY2PR02MB298.namprd02.prod.outlook.com>
 <CAL=_i_mR9ue7W_=zZX19Zm3XY1kPaJfoho2U3ZdExNPXWQwN8Q@mail.gmail.com>
 <BLU436-SMTP1486256AA36AFDB5A00EDABE2CB0@phx.gbl>
 <BY2PR02MB29887B1092A73C5458ACE0FACCB0@BY2PR02MB298.namprd02.prod.outlook.com>
 <CAL=_i_nZZQ74BVzy-4+XuPP72_U2ynNRDz5p0yEVNbd3x=ieeg@mail.gmail.com>
 <CAH-PCH7j13QQQ9hkdC8Cg5UG4UijCob4fsnk6GyYD6V_21+4Uw@mail.gmail.com>
 <1E7F9387-A836-46AC-BA62-E4141DDBB387@rouvenwessling.de>
Message-ID: <56968DCF.1090609@garfieldtech.com>
Date: Wed, 13 Jan 2016 11:47:59 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
 Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <1E7F9387-A836-46AC-BA62-E4141DDBB387@rouvenwessling.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] [VOTE] PHP 5's Support Timeline
From: larry@garfieldtech.com (Larry Garfield)

On 1/13/16 11:26 AM, Rouven Weßling wrote:
>> On 13 Jan 2016, at 16:23, Ferenc Kovacs <tyra3l@gmail.com> wrote:
>>
>> I don't think we can avoid some confusion, we could have had a three way
>> vote here (keep the current, expand #1, expand #2) but then people would
>> argue that the tho expand options should win in sum or one of those
>> separately. We could have delayed the second vote after the first one, but
>> then it could be argued that somebody would have voted differently if they
>> knew the options for the second vote (or even the progress of the votes)
>> beforehand. Or Zeev could have picked one of the two dates, and seeing the
>> results it is entirely possible that the vote would have failed regardless
>> of the date picked (assuming that the No voters would have voted no
>> anyways, and some of the yes voters would have voted no because of their
>> disagreement with the proposed date) which seems to be a bad outcome seeing
>> how the yes-no vote went to 42:2.
>> So I don't think we had a objectively better alternative or how could
>> always have the best outcome with a simple vote of two options.
> I don’t have voting rights but I don’t think there is a problem with multiple votes in one RFC,
> even if they are chained (b only matters if a passes). What doesn't make sense is for the voting
> right to be restricted based on how one voted (may only vote in b if voted for a with option X).
>
> Of course most people would make the most restrictive choice in the second vote if they were
> against the whole RFC, but that would make it an effective reflection on how everyone feel.
>
> Best regards
> Rouven

That is essentially what IRV allows: First choice is A, but if A doesn't 
pass my next choice is B, and if that doesn't pass my next choice is C.  
At this point, I'm of the mind that any non-binary vote should use IRV.

IRV: https://en.wikipedia.org/wiki/Instant-runoff_voting

-- 
--Larry Garfield