Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82921
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.28 cause and error)
Message-ID: <54E2B9F2.7020704@garfieldtech.com>
Date: Mon, 16 Feb 2015 22:48:02 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <010b01d049fd$9a09a020$ce1ce060$@php.net>
In-Reply-To: <010b01d049fd$9a09a020$ce1ce060$@php.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Proposing [constructive] solutions (was: I quit)
From: larry@garfieldtech.com (Larry Garfield)

On 02/16/2015 10:31 AM, François Laupretre wrote:
>
>> - The leadership of the language is left to consensus, so that when
>> consensus cannot be reached, someone has to take on the role of mediator
>> / chairman / leader for the feature, and try to push through a compromise.
> I have no democratic solution for this. In the PHP spirit, as Zeev explained, if the RFC process doesn't bring a consensus before the vote, the discussion should stop and the RFC should be modified. Trying to push it to a 2/3 approval while people are fighting is counter-productive. In this regard, IMO (and I told her), Andrea should have withdrawn her RFC much sooner. It would have allowed to take more time for building the next one, and start a new discussion in a more constructive atmosphere. Upcoming feature freeze was probably the reason but the result is that we need to restart everything from scratch in a bitter atmosphere.

To be clear: consensus is not leadership.  Consensus cannot be 
leadership.  So the statement "leadership of the language is left to 
consensus" is a very explicit and deliberate statement that the language 
has no leadership.

That is, as I understand it, by design. But let's not pretend 
otherwise.  We have a leaderless language and development process, by 
design, with all of the negative side-effects that such a power-vacuum 
structure entails.

I'm not saying that as a criticism necessarily. It's just a fact, and we 
shouldn't pretend otherwise.

>
>> - The RFC process traditionally has only one voting phase, with a
>> Proof-Of-Concept patch completed, and voters expecting few
>> implementation details to change. So a lot of time has to be committed
>> to the details of a feature which might be outright rejected. It might
>> be more efficient if the principle of a change, details such as syntax,
>> and final implementation, could be considered separate phases.
> That's the tradition but I think it is quite open for improvements. While we are traditionally using one final vote with multiple options, nothing refrains anyone to organize informative pre-votes during discussion to test the popularity of a feature before he starts writing code, clearly stating that it is not the final vote. This would allow a better information from the community to the RFC author. The interest of such running pre-votes is that they can contain many more options than the final vote and can be started and closed at anytime during discussion. The only requirement is that everyone understands that it in *not* the final vote.

The FIG ran into a similar issue a while back.  The result is a somewhat 
different two-stage RFC process as described here:

https://github.com/php-fig/fig-standards/blob/master/bylaws/004-psr-workflow.md

It's imperfect, but it does provide extra structure that has been a huge 
improvement over the internals-like free-for-all that preceded it.  In 
particular, it allows members to vote on the concept of a PSR before the 
implementation.  IE, "do we want to have a spec dealing with HTTP 
messages" is a separate vote from "is this particular implementation of 
an HTTP message spec what we want to put our stamp on"?

Additionally, there's a separate spec and meta document.  The meta doc 
is specifically for things like "Why did you do X instead of Y?" and "we 
rejected Z outright for these reasons".  That said, people generally 
don't read the metadoc any more frequently than they read the same notes 
in Internals RFCs today, which often address the issue people are 
talking about for the 5th time. :-(

An exact replica of FIG's process is probably not going to fly for 
Internals for various good reasons, but it can hopefully serve as a 
source of ideas.

--Larry Garfield