Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128641
Precedence: list
MIME-Version: 1.0
Date: Fri, 05 Sep 2025 12:59:36 +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-LB1beBLxx71QrYEMiwKcF0gXcv=5VZo-k7aTKxuS0LXwQ@mail.gmail.com>
References: <53cdbf5b-7c6e-4ba1-9987-332634cab527@bastelstu.be>
 <CAPyj-LB1beBLxx71QrYEMiwKcF0gXcv=5VZo-k7aTKxuS0LXwQ@mail.gmail.com>
Message-ID: <fa34741442b7b7711f2b2296bf81890d@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-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