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