Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78707
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain pascal-martin.fr designates 176.31.99.170 as permitted sender)
Message-ID: <5459DB06.7050305@pascal-martin.fr>
Date: Wed, 05 Nov 2014 09:08:38 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <6DDFA9F9-EE41-4B53-846D-C771188F2A93@ajf.me>
In-Reply-To: <6DDFA9F9-EE41-4B53-846D-C771188F2A93@ajf.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] RFC Process: Should we hold two different votes?
From: mailing@pascal-martin.fr (Pascal MARTIN)



Le 05/11/2014 00:58, Andrea Faulds a écrit :
> Good evening,
>
> A lot of RFCs have been rejected because, while they proposed a feature people would like, the details were problematic. This has lead to these features sometimes being considerably delayed.
>
> So, in order to do something about this, here’s an idea: Why not hold two different votes on an RFC, similar to how legislation is passed in the UK’s House of Commons? The first is on whether the general principle of the RFC is sound. Once that’s passed, it’s clear the feature is wanted, so time can then be spent scrutinising the details of the proposal and making them acceptable. Then, a second vote can be held, which approves the RFC as a whole, and its patch (like our current votes do). This way:
>
> * Authors know quickly whether a feature has sufficient support (reading internals doesn’t necessarily tell you anything, as votes and numbers of positive/negative emails rarely align), without having to necessarily have done everything before the final vote
> * Bad ideas are rejected sooner
> * Good ideas with flawed implementations may succeed in the first vote and fail in the second, meaning there’s a clear agreement that it’s wanted but not with this implementation, allowing another RFC with an improved approach to perhaps be made later
>
> Does this sound like a good idea?
>

I really like this idea, which might help the RFC process in several ways:

People (especially those who are not involved much in PHP internals now) 
might hesitate less before working on a "principle" RFC, knowing they 
won't have to code a feature (which might take days or more) that may 
just not be accepted.

People not knowing C / PHP internals might suggest more "principle" 
RFCs. And if those pass with an overwhelming "yes", it might be easier 
for them to find support from current maintainers to help work on the 
implementation.

Also, it might be the right time to have different people voting, like:

  * Community (representatives of frameworks, UGs, ...), who are close 
to users but don't know C / PHP internals, should be able to vote on the 
"principle" RFCs.
  * While voting on "implementation" RFCs might be restricted to people 
who are closer to PHP -- mostly, those who can already vote today (like 
people with karma, or working on doc)

Like you said in your last point, it also allows for a more iterative 
work on implementation, if a "principle" is accepted but an 
"implementation" is not.

Though, I think there might not always be a need for "implementation" 
RFCs: if the implementation of a "principle" is trivial enough (like, 
for instance, adding a simple new function or changing the default value 
of a parameter), having to vote on the "implementation" could be a too 
heavy process.


-- 
Pascal MARTIN
http://blog.pascal-martin.fr
@pascal_martin