Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83145
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: <54E57C3F.5010002@garfieldtech.com>
Date: Thu, 19 Feb 2015 01:01:35 -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>	<54E2B9F2.7020704@garfieldtech.com> <CAKOpQSwWcGfxGiORZM9-C8jx3L8zc99fND-UeNg_O73wEWnSHA@mail.gmail.com>
In-Reply-To: <CAKOpQSwWcGfxGiORZM9-C8jx3L8zc99fND-UeNg_O73wEWnSHA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Proposing [constructive] solutions (was: I quit)
From: larry@garfieldtech.com (Larry Garfield)

On 02/17/2015 01:15 AM, Kris Craig wrote:
>> 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.

"Flat consensus" vs. "strong dictator deciding everything" is a false 
dichotomy. I make that assertion based on 9 years of experience in 
Drupal, which despite having a BDFL in theory (Dries) is mostly 
"consensus of whoever notices" run. It's a problematic structure that we 
are currently having some difficult internal discussions about, because 
it doesn't scale and it's leading to burnout issues, work slowdowns, and 
other issues.

For background, see the presentation I gave on complex informal 
structures at DrupalCon Amsterdam, which includes a wide array of links 
to further reading on why informal semi-consensus structures are so 
problematic:

https://amsterdam2014.drupal.org/session/managing-complexity

> 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>

That was how FIG started, certainly, under the name "PHP Standards 
Group". I was one of those on the Internals list who called them to task 
for the initial arrogance before they were booted off of php.net.

However, that was 6 years ago.  FIG, while still far from perfect, has 
evolved into a much more productive and useful organization, and I would 
now put them squarely in the Force For Good(tm) category rather than 
Force For Evil(tm).  That wasn't the case originally, but it is now.  
The creation of common baseline standards has been a major driver in the 
PHP Renaissance, and is part of what made tools like Composer possible 
and seeing the mixing and matching of code from Zend, Symfony, and 
others as well as modernization efforts like Drupal 8, the new PHP BB, 
ezPublish, etc.

(Disclosure: I joined FIG as the Drupal representative a few months 
after they were booted off of php.net, a position I still hold.  I also 
co-authored the current voting/process bylaw with Phil Sturgeon.)

> 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

There sounds like there's a great deal of discontent with the current 
minimalist process.  The current RFC process was "OMG too much 
structure" compared to the free-for-all that preceded it, but I don't 
think many people would disagree that adding such structure has greatly 
improved PHP and the tone of this list.  Structure is not a bad thing; 
bad structure is a bad thing.  It's important to understand the difference.

Your opinion of FIG is noted, but don't let your distaste for its 
founding (which I share) cloud you against a potential source of 
positive inspiration to improve PHP and the PHP development process.

--Larry Garfield