Hi
Am 2025-09-08 17:14, schrieb Larry Garfield:
Perhaps the latest changes already make the language a little less
awkward?
It's an improvement, but I think it can still be improved further.
It's still very verbose, and not in ways that I feel are necessary.
Would you be OK with me PR-ing a restructure to try and clarify
further, including the text above?
Sure. Please be careful not to introduce any changes to the actual
proposal, since I'm trying to keep each “functional” change in a
separate commit to make it easier to follow the evolution of the policy.
I might also want to add my own fixes on top, so it might also happen
that I use your text as a basis only (similarly to Ilija's suggestion).
As I said elsewhere, if we were an organization with that level of
formality and structure, I'd likely agree. But this project has
actively rejected even a modicum of structure or "enforcement" ability,
so it seems incongruous to have highly pedantic scheduling but
loosey-goosey everything else.
I believe that the development of PHP has become increasingly
structured, especially with the introduction of the policies repository
and the associated policy RFC process. This is the 4th policy RFC
(acronym naming, exception hierarchy, abstain vote, this one) I'm doing.
It does not seem useful to me to make the policy less formal, just
because PHP historically didn't have particularly well-written policies.
The goal of the RFC is to fix that.
Also, I think this is new:
Yes, I've added that part on Friday in response to Rob (implicitly)
asking for clarification whether or not RFCs may change after the vote
started (specifically whether the voting deadline may change).
If issues with an accepted RFC are noticed during implementation, an
errata
section explaining the necessary changes SHOULD be added.
We should include guidance on what level of changes are acceptable and
which would require a new RFC, or even possibly unaccepting an RFC.
Historically that was solved by “simple agreement” (i.e. write to the
list and it's okay if no one complains) if it's an obvious oversight and
actual RFCs for less obvious changes or if someone asks for them. I'm
not sure if this should be part of *this* RFC, since the “minor changes
are okay without RFC” policy is part of the “Release Process” policy.
As examples:
1. Attributes went through 2-3 extra votes to fiddle with the syntax
after the initial RFC.
2. Hooks had a follow-up RFC to approve a non-syntax change to error
handling, in the name of performance.
3. Pipes had a non-RFC syntax change to handle the unexpected parsing
issue with arrow functions.
I'd argue that #3 was a larger change than #2, yet #2 had an RFC and #3
we decided did not need one. (Not suggesting any of the above was
wrong, they're just examples to show we're not currently consistent.)
In case of #3, the fix was just “disallowing” something entirely,
leaving maximum flexibility to decide on a fix in the future. I believe
the decision made for #2 was a different situation.
I would recommend we give this decision-making to the RMs. If a change
needs to be made post-vote, the RMs are empowered to decide if it needs
a follow-up RFC, follow-up informal discussion, or "just do it, it's
fine." (All of the above should still be included in Errata, of
course.)
See above, I believe this is already sufficiently clear based on the
“Minor change” policy.
Best regards
Tim Düsterhus
