Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84504
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CACwt+JdxCF=F-PzPtGsZJb0WapEzZk--Qb2CvMaowxr4m8-htw@mail.gmail.com>
References: <CAOsHV+uApxF=pQngonMppam2AEnW0Sm1ESAaB9exLH0K0hMBWA@mail.gmail.com>
	<CAGa2bXYx-MGjhHVkDRYsHSRR4b+x4ba5PVxdhw9W2B1z0fWCEQ@mail.gmail.com>
	<CAOsHV+td_i5Z3JPmPF5WT8gAvhPFReO28L3TGPaYWgybSVnbSA@mail.gmail.com>
	<CAGa2bXbgDcjXWgoDw_X61KDbeiV_tcHpGk5RFSFsnQ1-LSNVPw@mail.gmail.com>
	<CAOsHV+tY4CmLD6tYt7R9eiNkBb9ibh4sjAVD0oysJTCuTY25Tw@mail.gmail.com>
	<CAGa2bXYtbhOg4XqniTtZj-rz-E7cc=C1cmqGSmphLmbN+cqASA@mail.gmail.com>
	<CAOsHV+vhvYD5JoyuKQOOmDzbN0rurGX58eMuRjn4cmH3H9gvsw@mail.gmail.com>
	<CAGa2bXa0=gZ=+5oSWp-kRBpWXoozHEdJb1-nuKN9r6RmGZj8Sw@mail.gmail.com>
	<CAOsHV+vjPxFZhN-OH8+5S57tK_P_G80B+HujXy07zeExOEMNVg@mail.gmail.com>
	<CACwt+JdxCF=F-PzPtGsZJb0WapEzZk--Qb2CvMaowxr4m8-htw@mail.gmail.com>
Date: Tue, 10 Mar 2015 11:02:14 -0400
Message-ID: <CAAyV7nEZBasQuePh_P+GRwWOCc+WvPF1Cj6rH7KVB6UkO+EHxQ@mail.gmail.com>
To: Patrick ALLAERT <patrickallaert@php.net>
Cc: marcio3w@gmail.com, Yasuo Ohgaki <yohgaki@ohgaki.net>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Voting choice for language changes (Was: "Re:
 [PHP-DEV][RFC][DISCUSSION] Strict Argument Count")
From: ircmaxell@gmail.com (Anthony Ferrara)

Patrick,

My viewpoint is that options in an RFC are dangerous. I would much
rather have a single RFC, with a single vote (yes/no). I think we
should be discouraging the options as much as possible.

The reason is simple: an RFC should be an encapsulated idea, not a
menu of options. The author should take a stance. If there are details
that the author can't decide on, then either take a straw poll in the
mailing list, or create a separate RFC for that option.

The problem with options is that it makes the vote much more
confusing. With 3 options, you have 3 different proposals. Some recent
votes have had upwards of 12 different proposals built in to a single
RFC (2 options + 3 options + 2 options). It's enough to ask someone to
read and understand one proposal completely without having them have
to comprehend all the possible permutations of voting outcomes.

It also encourages weird voting patterns. Take your example of No/Yes,
A/B/C. In that case, you have 4 permutations as you pointed out. But
what's deeper, is how should someone vote if they are opposed to B? I
mean opposed, not just preferring a different one? The tendency would
likely be to watch the vote and if it looks like B will pass, vote no
on the entire proposal.

Can we please come down to a single RFC, with a single vote yes/no?
It's easier to understand, easier to manage and has less possibility
of gaming.

Anthony

On Tue, Mar 10, 2015 at 10:39 AM, Patrick ALLAERT
<patrickallaert@php.net> wrote:
> Hello,
>
> Le ven. 6 mars 2015 =C3=A0 00:44, Marcio Almada <marcio.web2@gmail.com> a=
 =C3=A9crit :
>>
>> You are right about this. I'll setup a yes/no vote + a vote to decide
>> between E_WARNING (for consistency), E_DEPRECATED or E_STRICT. For me th=
is
>> is just a detail but maybe it's very important to others, so better to l=
et
>> each voter decide upon it.
>>
>
> In case of language changes, shouldn't the 2/3 of majority be required at
> any levels?
>
> In situations like:
>
> Main feature: No/Yes
> Option: A, B or C
>
> My gut feeling is that it would be better to rally a 2/3 majority of peop=
le
> behind one of:
> No / Yes (A) / Yes (B) / Yes (C)
> in order to not dilute the importance of language changes.
>
> It would prevent accepting an important change where a lot of people agre=
es
> on a general idea but have strong opinions/arguments on
> implementation/details.
>
> Cheers,
> Patrick