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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
