Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78709
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.41 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <6e466b61fad8a6999c3bf021f57854b6@mail.gmail.com>
References: <6DDFA9F9-EE41-4B53-846D-C771188F2A93@ajf.me> <6e466b61fad8a6999c3bf021f57854b6@mail.gmail.com>
Date: Wed, 5 Nov 2014 10:18:00 +0100
Message-ID: <CAMUwpuS=88G4LzuCWqA0dDnF2Yvkn-eF5BgyJ9w8cNq=RXN9KQ@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Andrea Faulds <ajf@ajf.me>, 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: jpauli@php.net (Julien Pauli)

On Wed, Nov 5, 2014 at 9:35 AM, Zeev Suraski <zeev@zend.com> wrote:
>> -----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 U=
K=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 a=
nd
> we should be respectful of people's time.  While dividing this to two vot=
es
> may save the RFC proposer some time, especially in case his proposal does=
n't
> pass the initial vote (so that they won't have to invest efforts in creat=
ing
> 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 deta=
ils
> 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 tha=
t
> the devil is in the details, once these details are known there may not b=
e 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 wit=
h
> an informal discussion on internals, before the RFC is even written, to
> gauge people's response.
>
> Zeev


I like Zeev's answer here, in the meaning that I have the feeling that
everyone would vote +1 to add many cool things to PHP.
But internally, things are sometimes hard to implement, or just too
big to get in without changing all the code or may have bad
interaction with each other (like RFC-A will conflict in
implementation with RFC-B).

People with no idea on how things work internally would probably vote
yes to every new idea, without really measuring the impact it will
have on the code base, both on development *and* maintaining the new
code base (which is pretty hard to do as well).

It's like saying "I'm +1 for having flying cars, now people I let you
do it and I have no idea on how that will work".
I don't really like such direction. We are all here technical people,
and should vote global decision with a clue on how this will
technically be achieved.

I'm afraid such a new process will see everybody say +1 to everything,
but barely few people really working on the "real" things =3D> the code.
Or having RFC voted +1 , but finally abandoned because of
implementation details that had not been clear enough in the RFC.

Also, an idea cannot come without specification details, as-is , an
idea is just an idea =3D> something really abstract and useless until
you give some implementation details.

Saying yes just to say yes, it's like Christmas : yes, I do want tons
of present. That does not make thing move forward

Julien.P