On Mon, Nov 11, 2024, at 1:14 AM, John Coggeshall wrote: > On Nov 11 2024, at 12:03 am, Larry Garfield <la...@garfieldtech.com> wrote: >> >> First off, the obligatory "it was open for discussion for a month, and now >> you mention this?" > > I apologize for that, wasn't intentional. Unfortunately a whole pile of > personal matters landed on my head between ... let's say October and > November 6th that kept me from focusing on internals. As might be > expected, the vote refocused my attention.
Quite... > I think this is worth discussing a bit more below,... > > TL;DR; I will at a minimum abstain from voting on this rather than vote > "no" as my intent isn't to derail progress here. Thank you. I appreciate your openness here. > As I eluded to above, I am certainly not suggesting we endorse a single > framework. I guess at the end of the day I've got a number of issues > with the specifics of the language around how decisions are made in > this doc, but I will concede that at least there is a document here > that can be refined which is indeed a step forward. If you're > interested some the concerns I have are (I'm focused on the maintainer > bits below but I think they also largely apply to the marketing > criteria as well): > > • I don't think the "version 1.0" requirement is a good one, only > because I strongly suspect it wouldn't take me very long to find a very > reasonable library that for whatever reason is 0.8 or something... so > now it can't be used, unless there is an RFC? See, I find the 1.0 requirement far less arbitrary than the minimum maintainers requirement. Assuming the library is following semver (most do, mostly), having a 1.0 gives us a reasonable expectation that the API won't change out from under us in a minor release. In a 0.x, that is by definition a risk, making it not necessarily stable enough to trust. (There are indeed some libraries that stay in 0.x land forever, despite being well maintained. These maintainers are Doing It Wrong(tm) and need to stop.) > • I don't understand what the point of the "Explicitly approved" list > is, if the point is any and all libraries which meet the acceptance > criteria can be used without asking for permission then they are by > default approved, right? The criteria are by necessity squishy. They're guidelines and heuristics, but the PHP ecosystem is far too complex for a series of yes/no binaries to make sense in most cases. And different people will no doubt interpret different cases differently. So as a hypothetical, suppose someone tries to mention ramsey/uuid on a marketing page. Another person objects, saying that it isn't important enough of a library to the ecosystem as a whole to warrant a mention. We resolve that conflict by having an RFC to add ramsey/uuid to the "this is definitely OK according to these criteria" list. If it passes, then we've resolved it: Mentioning ramsey/uuid is now explicitly OK on marketing pages, and if someone objects in the future we can say "look, we already voted on it and decided it was OK. Stop fussing." > • The library should have an active developer community of at least 2 > developers, and the library should have an currently active development > history of at least 1 year. I see the intent here, to ensure a library isn't going to be abandoned. However, the vast majority of libraries are single-developer. Even those that have contributions from others are realistically one-person-projects. Looking at ramsey/uuid again (sorry Ben, don't mean to pick on you), ramsey himself has 705 commits. Dependabot is #2. The second human is jmauerhan at 35, so around 5% ish as many, all before 2020. Does that count as an "active developer community of at least 2"? I'd say no. But that library is a staple of the ecosystem and has been for over a decade. It's not going anywhere. It's probably more reliably maintained than many 2-3 person projects that never really got off the ground. So even if we could quantify what counts as "2 active developers", it's still a fairly poor signal of reliability. --Larry Garfield
