On Mon, Oct 7, 2024, at 2:54 AM, Jakub Zelenka wrote:
> Hi,
> 
> On Wed, Oct 2, 2024 at 7: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
> 
> I think it would be better to have just a light RFC introducing the basic 
> idea and create a PR against policies repo because that's where the wording 
> matters. We should be really voting on those PR's rather than create policy 
> RFC and then create PR that might have a different wording...

That would seem to be introducing a whole new process for making policy 
changes, because right now there is no voting process for PRs for any of the 
PHP organization repositories.

Maybe policy RFCs like this should have accompanying implementation PRs like 
many of the non-policy RFCs do, but I'm not sure that voting on PRs for policy 
changes makes any more sense than voting on PRs for code changes.

Jim

Reply via email to