Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120154
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-374-g72c94f7a42-fm-20230417.001-g72c94f7a
Mime-Version: 1.0
Message-ID: <a716f297-b4be-4b10-aede-1468a9b4f965@app.fastmail.com>
In-Reply-To: 
 <CAAKU0unGGoN4-u0kUHB7DvjKHZgSgSTRkUywbx==Uzzt+skNxQ@mail.gmail.com>
References: 
 <CAEKnhAEzEBRHO+=3KSLCveEWZ7ZwxtD0MJL-=VG6nz2xMcvbMA@mail.gmail.com>
 <CAAKU0unGGoN4-u0kUHB7DvjKHZgSgSTRkUywbx==Uzzt+skNxQ@mail.gmail.com>
Date: Fri, 28 Apr 2023 18:27:49 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] PHP Technical Committee
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Apr 28, 2023, at 3:17 PM, Levi Morrison via internals wrote:
> On Fri, Apr 28, 2023 at 4:01=E2=80=AFAM Jakub Zelenka <bukka@php.net> =
wrote:
>>
>> Hi,
>>
>> The vote is now open for the RFC about introduction of the PHP Techni=
cal
>> Committee:
>>
>> https://wiki.php.net/rfc/php_technical_committee
>>
>> Regards
>>
>> Jakub
>
> Do we really need this level of bureaucracy? I mean... I know
> someone's work got rejected and that wasn't a great situation, and I
> feel for them because it was handled poorly IMO. But this committee
> seems like a lot of work for... what? Being able to solve an
> occasional disagreement? This seems like more work than it solves,
> with some bad downsides if "the wrong people" get in there. You know,
> the power-hungry egotistical kind of people.

It's not just about dealing with the occasional fights like over rearran=
ged include statements, although it is partially that.  It's also about =
making it clear who the technical leaders are.  Right now, PHP badly suf=
fers from the Tyranny of Structurelessness (https://www.jofreeman.com/jo=
reen/tyranny.htm).  The TC provides a fairly low-effort way to help with=
 that. =20

How does a new dev know "how things are done?" around here?  At a code l=
evel.  Basically they don't.  They have to ask people, but who to ask?  =
Whose answer is more trustworthy?  They don't know.

The TC is a clear place to "set the tone", technically speaking.  If it =
often doesn't do much, well, great.  That means things are moving smooth=
ly.  But it's always good to have tools and processes in place *before* =
you need them.

> with some bad downsides if "the wrong people" get in there. You know,
> the power-hungry egotistical kind of people.

This is a common strawman argument, frankly.  Yes, any time you have a p=
osition of any authority, it's possible for it to be usurped by a malici=
ous actor.  But malicious actors can take over unstructured systems just=
 as well.  And benevolent actors have a harder time opposing them and do=
ing good when hamstrung by a lack of structure or clear process.

There is a vast, vast range of possible structures between total anarchy=
 (current PHP status quo) and a malevolent dictator lording over everyon=
e.  Almost every major OSS project has some kind of structure and leader=
ship and decision making process.  PHP is the only meaningful exception.

That's not because we're special.  PHP has succeeded thus far despite ha=
ving an anarchic anti-pattern structure, not because of it.

The TC is a small, modest, but productive step forward to resolve practi=
cal issues.  That's exactly the sort of thing PHP keeps telling people i=
s how to get things done.  So, let's get things done.

--Larry Garfield