Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128799
Precedence: list
MIME-Version: 1.0
References: <53cdbf5b-7c6e-4ba1-9987-332634cab527@bastelstu.be>
 <29c9d6cfcc2928d3805596416edbff6e@bastelstu.be> <92a59844e30a9ca0550456886913fdb1@bastelstu.be>
In-Reply-To: <92a59844e30a9ca0550456886913fdb1@bastelstu.be>
Date: Thu, 9 Oct 2025 19:54:05 +0200
Message-ID: <CAPyj-LD6QmUxNPrpC5OHh5=cGwLif_ALUWzJCwjZeEHs8=bN5g@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 Wed, Sep 24, 2025 at 9:09=E2=80=AFAM Tim D=C3=BCsterhus <tim@bastelstu.b=
e> wrote:
>
> Hi
>
> Am 2025-09-19 10:55, schrieb Tim D=C3=BCsterhus:
> >> 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
>
> All that said, I'm happy to hear some feedback on whether or not the
> updated phrasing is looking good to you? :-)

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.

> 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 mor=
e than 7 days before the vote is officially opened (=E2=80=9CIntent to Vote=
 lifetime=E2=80=9D).

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.

> 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 av=
oided 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.

> The voting period MAY be canceled within the first 2 days in case of seve=
re 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 cou=
ld have simply declared =E2=80=9Can issue=E2=80=9D and updated it with thei=
r 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.

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).

Ilija