Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128620
Precedence: list
MIME-Version: 1.0
References: <53cdbf5b-7c6e-4ba1-9987-332634cab527@bastelstu.be>
In-Reply-To: <53cdbf5b-7c6e-4ba1-9987-332634cab527@bastelstu.be>
Date: Thu, 4 Sep 2025 00:14:43 +0200
Message-ID: <CAPyj-LB1beBLxx71QrYEMiwKcF0gXcv=5VZo-k7aTKxuS0LXwQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Tim

On Fri, Aug 29, 2025 at 10:21=E2=80=AFPM Tim D=C3=BCsterhus <tim@bastelstu.=
be> wrote:
>
> Please find the RFC at: https://wiki.php.net/rfc/rfc_discussion_and_vote
> And the PR at: https://github.com/php/policies/pull/23

Thank you for your initiative to solidify the unwritten rules we've
been following for a while. A few comments:

> When making non-editorial / non-typographical changes to the normative se=
ction 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.

> 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 c=
hanges.

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.

> Similarly RFC authors SHOULD NOT proceed with an announced vote if new di=
scussion 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.

As others have noted, I also think some tolerance for the hourly
requirement is reasonable.

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.

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.

Ilija