On Wed, Oct 2, 2024, at 12:17 PM, Deleu wrote: > On Wed, Oct 2, 2024 at 3:38 PM Larry Garfield <la...@garfieldtech.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 code. (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. >> >> I'm sure we'll bikeshed it to death, but please keep an open mind about the >> concept in the first place. PHP is more than just php-src, and that'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. >> >> https://wiki.php.net/rfc/third-party-code >> >> *Puts on trusty flame-retardant suit* >> >> -- >> Larry Garfield >> la...@garfieldtech.com > > Good writeup. Although I was more of a fan of Jim's RFC which just targets > the main issue of bringing up in the mailing list that PHP cannot use X > because "endorsement", this is also a good alternative. > > My only problem with it is in the "discussion" section: > >> Symfony, Laravel, Slim, Yii,WordPress, Drupal, TYPO3, etc. - While Laravel >> and Symfony are the market leaders in PHP frameworks, and WordPress >> dominates the CMS-oid market, it is a highly dynamic market, with literally >> dozens of players that have reasonable use. That makes listing them in the >> documentation without “playing favorites” essentially impossible, and >> therefore none should be listed by name. They should also not be used >> directly to build any PHP tooling, again to avoid the appearance of >> endorsement. However, it may make sense to list several of them in passing >> in marketing material, explicitly noting that they are just some among many >> options. > > It's 2024. If the foundation is hiring developers to improve the language > across the board (internals, docs, website, processes, marketing, visibility, > 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.
To clarify, the PHP Foundation is not hiring developers to do "pure documentation work, PHP packages, websites, or translations" according to their 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 this sort of decision making is up to the PHP Foundation, these are issues for the PHP community to decide and the RFC process is really the only accountable mechanism for that. Jim
