Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125737
Feedback-ID: ia2404087:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 02 Oct 2024 17:07:31 -0700
To: internals@lists.php.net
Message-ID: <d589ad23-a918-4c15-bea0-417d4a909a72@app.fastmail.com>
In-Reply-To: 
 <CADK1yXJMOSRY++NO3amtKip4wJPw-sVPcCJ0kAFU8HwYGPL38Q@mail.gmail.com>
References: <92b537ac-62f4-435c-bf55-07223cfa1915@app.fastmail.com>
 <CADK1yXJMOSRY++NO3amtKip4wJPw-sVPcCJ0kAFU8HwYGPL38Q@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Policy on 3rd party code
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: jimw@trainedmonkey.com ("Jim Winstead")

On Wed, Oct 2, 2024, at 12:17 PM, Deleu wrote:
> On Wed, Oct 2, 2024 at 3:38=E2=80=AFPM Larry Garfield <larry@garfieldt=
ech.com> wrote:
>> Since Jim's RFC proposal was criticized for being too vague, I hereby=
 offer a somewhat more prescriptive policy proposal on using 3rd party c=
ode.  (With JIm's blessing.)  It's still more heuristics than rules, but=
 I think that's the right approach generally.  It also includes a voting=
 mechanism to resolve edge cases when they come up.
>>=20
>> I'm sure we'll bikeshed it to death, but please keep an open mind abo=
ut the concept in the first place.  PHP is more than just php-src, and t=
hat's a good thing.  We need to catch up with that reality, while at the=
 same time maintaining a reasonable neutrality about projects Internals =
doesn't manage directly.
>>=20
>> https://wiki.php.net/rfc/third-party-code
>>=20
>> *Puts on trusty flame-retardant suit*
>>=20
>> --=20
>>   Larry Garfield
>>   larry@garfieldtech.com
>=20
> Good writeup. Although I was more of a fan of Jim's RFC which just tar=
gets the main issue of bringing up in the mailing list that PHP cannot u=
se X because "endorsement", this is also a good alternative.
>=20
> My only problem with it is in the "discussion" section:
>=20
>> Symfony, Laravel, Slim, Yii,WordPress, Drupal, TYPO3, etc. - While La=
ravel and Symfony are the market leaders in PHP frameworks, and WordPres=
s dominates the CMS-oid market, it is a highly dynamic market, with lite=
rally dozens of players that have reasonable use. That makes listing the=
m in the documentation without =E2=80=9Cplaying favorites=E2=80=9D essen=
tially impossible, and therefore none should be listed by name. They sho=
uld also not be used directly to build any PHP tooling, again to avoid t=
he appearance of endorsement. However, it may make sense to list several=
 of them in passing in marketing material, explicitly noting that they a=
re just some among many options.
>=20
> It's 2024. If the foundation is hiring developers to improve the langu=
age across the board (internals, docs, website, processes, marketing, vi=
sibility, etc), it makes no sense that these folks (or any volunteer for=
 that matter) be explicitly and unquestionably denied the opportunity or=
 conversation to modernize the system which PHP tooling is built upon.=20

To clarify, the PHP Foundation is not hiring developers to do "pure docu=
mentation work, PHP packages, websites, or translations" according to th=
eir recent call for applications for the next round of developers:

https://thephp.foundation/blog/2024/09/17/application-form-2025/

I bring this up because I don't want people to get the impression that t=
his sort of decision making is up to the PHP Foundation, these are issue=
s for the PHP community to decide and the RFC process is really the only=
 accountable mechanism for that.

Jim