Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78708
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.179 as permitted sender)
References: <6DDFA9F9-EE41-4B53-846D-C771188F2A93@ajf.me>
In-Reply-To: <6DDFA9F9-EE41-4B53-846D-C771188F2A93@ajf.me>
MIME-Version: 1.0
Thread-Index: AQFiI09DE0D0p8eNxCnURgpOO0yuPJ0tXPkw
Date: Wed, 5 Nov 2014 10:35:38 +0200
Message-ID: <6e466b61fad8a6999c3bf021f57854b6@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: RE: [PHP-DEV] RFC Process: Should we hold two different votes?
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Andrea Faulds [mailto:ajf@ajf.me]
> Sent: Wednesday, November 05, 2014 1:59 AM
> To: PHP internals
> Subject: [PHP-DEV] RFC Process: Should we hold two different votes?
>
>Why not hold two
> different votes on an RFC, similar to how legislation is passed in the UK=
=E2=80=99s
> House of Commons?

I can think of two key reasons for why not:

1. It's more hassle.  Unlike parliament members, this work is voluntary and
we should be respectful of people's time.  While dividing this to two votes
may save the RFC proposer some time, especially in case his proposal doesn'=
t
pass the initial vote (so that they won't have to invest efforts in creatin=
g
a detailed proposal), for everyone else, this is going to be a lot more
hassle.

2. In my experience, there are few cases where the details of the RFC don't
affect my yes/no decision.  Voting 'in principle' without having the detail=
s
bares very little significance.  Also, running two votes may also create
perception in some people's minds that if an RFC passed the initial vote,
it's now only a matter of deciding between options, when again, given that
the devil is in the details, once these details are known there may not be =
a
majority in favor of the feature in the first place.

All in all, I don't see why this extra step cannot be simply replaced with
an informal discussion on internals, before the RFC is even written, to
gauge people's response.

Zeev