Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128658
Precedence: list
MIME-Version: 1.0
Date: Mon, 08 Sep 2025 17:54:57 +0200
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules
In-Reply-To: <c252a4ef-f9da-423e-92b4-4babbbc336bb@app.fastmail.com>
References: <53cdbf5b-7c6e-4ba1-9987-332634cab527@bastelstu.be>
 <4624748F-0C62-4E3C-81D0-5CDC56FEC55F@nicksdot.dev>
 <c177c3340f458a4de58fefb4107c1753@bastelstu.be>
 <dd1e34df1b5b740948ab24f0b4bd367b@bastelstu.be>
 <68c44ae3-8e1b-419d-9c30-906b9c2d5a81@app.fastmail.com>
 <0f32efec-b6c9-4ec0-96bf-297da722aaf1@bastelstu.be>
 <e1a75f2c-f7c0-45ff-a9a9-12088df2e978@app.fastmail.com>
 <4b809fc105b2cb53992dedde44cf6bc8@bastelstu.be>
 <c252a4ef-f9da-423e-92b4-4babbbc336bb@app.fastmail.com>
Message-ID: <b080a99031cd169e9c024da7183e292a@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

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