Re: [RFC] Clarify discussion and voting period rules

From: Date: Fri, 05 Sep 2025 10:59:36 +0000
Subject: Re: [RFC] Clarify discussion and voting period rules
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-128641@lists.php.net to get a copy of this message 
Hi

Am 2025-09-04 00:14, schrieb Ilija Tovilo:

When making non-editorial / non-typographical changes to the normative section of the RFC text (i.e. to the actual proposal, excluding future scope, rejected features and references) the discussion period MUST be extended.


It should also be acceptable to add examples whose semantics are
already clearly specified textually.


Adding examples is currently considered a “minor change” (i.e. 1 week). I consider that useful, so that participants are able to double-check all examples for correctness. It's not uncommon for examples to not actually work or to be out-of-sync with the “formal proposal”. Given that examples are also intended to help folks understand the RFC better, they might also make people realize that they misunderstood something that was already there, which might lead to additional useful discussion.

I therefore believe that examples should not be treated as a “purely editorial” change.


The discussion period MUST be extended by 2 weeks (336 hours) in case of major changes. It MUST be extended by 1 week (168 hours) in case of minor changes.


Do you think there's a risk that known issues will be covered up to
dodge the extended discussion period, most notably to avoid missing
feature freeze? Of course, this risk already exists, but with less
wiggle room it may increase further.


Sure, that is a risk. But I believe that folks are sufficiently diligent to call that out in the voting thread and to vote accordingly. Intentionally doing a worse version of an RFC to meet a deadline does not seem to be a wise choice on the RFC author's end.


Similarly RFC authors SHOULD NOT proceed with an announced vote if new discussion points are brought forward after the voting announcement.


Larry has already touched on this. The policy should define "new
discussion points". It would be frustrating if some obscure but new
suggestion can make RFCs miss the deadline. Maybe this can be worded
in a way that encourages the author to incorporate late feedback and
to NOT start the vote if it would objectively improve the proposal. I
realize the policy says SHOULD NOT, but a newer contributor might very
well interpret this as frowned upon.


I'm happy to accept suggestions for a good phrasing.


I think you should also define what the consequences of failing to
adhere to the policy are. Does it invalidate the vote? Who can call
for the consequences to be implemented? Can the vote be restarted when
the minimum discussion period ends? Etc.


I have put some thoughts into my reply to Rob: https://news-web.php.net/php.internals/128634. I'm happy to hear what others think and will then incorporate that in the proposal.


Side-note: It might be useful to call this time the cooldown period.
I.e. major changes (including the first announcement of the RFC)
require a 2 week cooldown period, minor changes require a 1 week
cooldown period. During this period, no new (reasonable) discussions
or changes to the specification should happen.


I've already made the rename yesterday.

Best regards
Tim Düsterhus

Thread (40 messages)

« previous php.internals (#128641) next »