Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82927
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54E2B9F2.7020704@garfieldtech.com>
References: <010b01d049fd$9a09a020$ce1ce060$@php.net>
	<54E2B9F2.7020704@garfieldtech.com>
Date: Mon, 16 Feb 2015 22:15:50 -0800
Message-ID: <CAKOpQSwWcGfxGiORZM9-C8jx3L8zc99fND-UeNg_O73wEWnSHA@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113d19d66d1d1f050f42a2f8
Subject: Re: [PHP-DEV] Proposing [constructive] solutions (was: I quit)
From: kris.craig@gmail.com (Kris Craig)

--001a113d19d66d1d1f050f42a2f8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 16, 2015 at 7:48 PM, Larry Garfield <larry@garfieldtech.com>
wrote:

> On 02/16/2015 10:31 AM, Fran=C3=A7ois 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 mediato=
r
>>> / 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 pus=
h
>> 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 ne=
xt
>> one, and start a new discussion in a more constructive atmosphere. Upcom=
ing
>> 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.
>

On what basis are you making that assertion?  Consensus can be viewed as a
form of "group leadership", so long as there are sufficient processes
involved to facilitate that.  It need not necessarily lead to anarchy and
disorder, so I don't think it's necessarily a contradiction in terms.

The problem with having a single leader calling the shots in this case is
that it wouldn't make all the divergent views go away.  Instead, we'd
probably see a good half a billion or so new hooks to PHP emerging as
competing projects.  I think that would be far worse than what we have now,
even though what we have now is far from perfect.


>
> 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 al=
l
> 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. Whil=
e
>> we are traditionally using one final vote with multiple options, nothing
>> refrains anyone to organize informative pre-votes during discussion to t=
est
>> the popularity of a feature before he starts writing code, clearly stati=
ng
>> that it is not the final vote. This would allow a better information fro=
m
>> 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 message=
s"
> 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 sourc=
e
> of ideas.
>
>
The FIG is a good example of a relatively small group of individuals who
decided to draft their style preferences into a set of standards and tried
to impose that on everyone else by aggressively billing themselves as the
de-facto "official" standard.  I recall on more than one occasion one of
their organizers posting here trying to get us to endorse their standard as
the official PHP standard.  I've also seen them post on places like
StackOverflow on at least a couple occasions, interjecting on some
unrelated coding question to tell someone their code is not
standards-compliant and providing links to the PSR's.

I realize this is a tangent, but I always feel a need to push back now
whenever someone links to their PSR stuff as an example of what people
should be doing.  You're fine citing them; I just had to put that little
asterisk in there.  I'd hate to have to post a link to XKCD's "Standards"
strip again....  </soapbox>


> --Larry Garfield
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I think we should be careful not to make this more complicated than it
needs to be.  Adding a complex new set of rules wouldn't make things any
more or less civil.  On the whole, I think we do a fairly good job of that
on this list.  There can be very heated disagreements, sometimes, but
you'll find that when you put any group of developers together.  So long as
people behave like adults and make an effort to be civil, I don't think any
special action is needed on our part.  Like the FIG, I'd tend to look at it
as a solution in search of a problem.

--Kris

--001a113d19d66d1d1f050f42a2f8--