Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128860
Precedence: list
MIME-Version: 1.0
Date: Fri, 17 Oct 2025 10:40:26 +0200
To: Ilija Tovilo <tovilo.ilija@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules
In-Reply-To: <CAPyj-LD6QmUxNPrpC5OHh5=cGwLif_ALUWzJCwjZeEHs8=bN5g@mail.gmail.com>
References: <53cdbf5b-7c6e-4ba1-9987-332634cab527@bastelstu.be>
 <29c9d6cfcc2928d3805596416edbff6e@bastelstu.be>
 <92a59844e30a9ca0550456886913fdb1@bastelstu.be>
 <CAPyj-LD6QmUxNPrpC5OHh5=cGwLif_ALUWzJCwjZeEHs8=bN5g@mail.gmail.com>
Message-ID: <b7fdb7bbee975354180cc29c4230f417@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-10-09 19:54, schrieb Ilija Tovilo:
> Quite late with my response, but I went through the changes again. I
> already commented on the PR, but let me do it officially as well.

Thank you.

>> Prior to starting a vote, RFC authors MUST post an Intent to Vote 
>> message to the discussion thread. The post MUST be made at least 2 
>> days and no more than 7 days before the vote is officially opened 
>> (“Intent to Vote lifetime”).
> 
> I feel like the upper bound is a bit low. Effectively, the "intent to
> vote" message is an invitation to reread the RFC and provide more
> feedback. Complex proposals may want to give people sufficient time to
> work through the document, for which 7 days may be on the lower side.
> Of course, this is still possible by repeating the intent to vote
> message, but it seems a bit odd that this is necessary by following
> the proper procedure. Not a major issue though.

If the “Intent to Vote” causes the discussion to restart in a 
significant fashion, then IMO the RFC was not actually ready to go to 
voting yet. Expiring the Intent to Vote and requiring a new one after 
the new discussion is resolved is the intended behavior. Historically in 
most cases the Intent to Vote was already “I think I'm done, I plan to 
start the RFC in 2 days” and then that either happens, folks provide 
feedback or they at least say “Please give me another day or two, super 
busy right now”. So I don't expect the 7-day limit to become relevant in 
practice.

>> After the voting period has started, including after the vote closed 
>> and the RFC is either accepted or declined, there MUST NOT be any 
>> further Major or Minor changes to the RFC text and making editorial 
>> changes SHOULD be avoided for the avoidance of doubt.
> 
> The property hooks RFC had ~50 examples and we found at least a
> handful of mistakes only after the RFC was accepted. I don't think
> this is a rare occurrence. Given examples are frequently shared as a
> single source of truth, IMO it should be acceptable to fix mistakes
> iff they are not directly related to the described semantics. I.e. if
> some mistake obviously contradicts the vast majority of the document,
> it should be ok to fix it.

If it's *obviously* contradicting, I would consider it a typo fix. If 
it's not obvious, folks that only read the examples (which I expect to 
be a significant amount, since examples are much more approachable) 
might be misled and might want to change their vote as a result of that. 
Thus this type of fixes to the examples should not just happen casually.

As an example, during my review of the current PFA RFC, I found several 
examples that contradicted my understanding of the “prose semantics”. In 
some cases the example was incorrect, but in other cases the “prose” was 
incorrect or unclear and the example correctly showcased what was 
intended to be proposed. It's thus not easy to say that the prose is 
authoritative.

>> The voting period MAY be canceled within the first 2 days in case of 
>> severe issues with the RFC.
> 
> I don't think this restriction is necessary. Tim mentioned to me
> off-list it was motivated by this message:
> https://externals.io/message/128594#128724. If the vote is passing and
> a bigger issue is discovered, allowing the authors to retract the vote
> seems like the better approach than relying on voters to change their
> vote, especially if there's not enough time for a follow-up RFC. If
> the vote is failing, keeping it going only wastes time when a solution
> could already be discussed. The linked message says:
> 
>> Had this policy existed, taking what feedback I had already gotten, I 
>> could have simply declared “an issue” and updated it with their 
>> feedback; restarting the vote.
> 
> But I don't think this is true. Any fix for an issue would be
> classified as a major change, thus requiring a minimum cooldown period
> of 2 weeks. This seems equivalent to creating a new RFC and putting
> that to a vote after 2 weeks, which FWIU remains possible.

Does anyone except Ilija have an opinion on this?

> Regarding the errata section: If the original text or examples may not
> be altered, it would be useful to at least allow adding info boxes to
> examples whose semantics have changed (for the same reason as
> mentioned above, examples are frequently the only thing people pay
> attention to).

That makes sense to me. I don't think the proposed policy text disallows 
this, but I'll look if I can spell it out more explicitly that this is 
encouraged.

Best regards
Tim Düsterhus