[PHP-DEV] [VOTE] Clarify discussion and voting period rules

Mailing Lists php.internals
1

Hi

I just opened voting on the "Clarify discussion and voting period rules" RFC. Please find the following resources:

- RFC Text: PHP: rfc:rfc_discussion_and_vote
- Implementation PR: Clarify discussion and voting period rules by TimWolla · Pull Request #23 · php/policies · GitHub
- Discussion Thread: php.internals: [RFC] Clarify discussion and voting period rules

The RFC contains a single primary vote requiring a 2/3 majority. Voting will close 2025-11-20 09:30:00 UTC.

----------------

As during the discussion, I'd like to explicitly spell out some of the things that I took into account.

It is now 2025-11-06 08:54 UTC (and will be a little later when I actually hit send).

- The last change to the RFC was a Major Change on 2025-10-23 07:37:43 UTC: php.internals: Re: [RFC] Clarify discussion and voting period rules
- The Intent to Vote announcement was sent on 2025-11-04 08:45:24 UTC: php.internals: Re: [RFC] Clarify discussion and voting period rules
- There was no further feedback to take into account after the last Major Change (and thus neither after the Intent to Vote).

A little more than 14 days have passed since the last major change. A little more than 2 days have passed since the Intent to Vote announcement. Both is strictly within the proposed rules. The RFC was not inactive, since the last email was my Major Change announcement, which happened less than 42 days ago.

This email contains all the necessary information, namely the link to the RFC text, Discussion Thread, a list of the number of votes to cast and the end date. I also included a link to the implementation, since this is the main relevant thing for a policy RFC. Voting will close a little over 14 days from now. I have specified some buffer room to account for “mail delivery delay”.

I will make sure to add a link to the archives of the voting thread as soon as I see it appear in the archives.

Best regards
Tim Düsterhus

2

On Thu, Nov 6, 2025, at 10:02, Tim Düsterhus wrote:

Hi

I just opened voting on the “Clarify discussion and voting period rules”
RFC. Please find the following resources:

The RFC contains a single primary vote requiring a 2/3 majority. Voting
will close 2025-11-20 09:30:00 UTC.

As during the discussion, I’d like to explicitly spell out some of the
things that I took into account.

It is now 2025-11-06 08:54 UTC (and will be a little later when I
actually hit send).

A little more than 14 days have passed since the last major change. A
little more than 2 days have passed since the Intent to Vote
announcement. Both is strictly within the proposed rules. The RFC was
not inactive, since the last email was my Major Change announcement,
which happened less than 42 days ago.

This email contains all the necessary information, namely the link to
the RFC text, Discussion Thread, a list of the number of votes to cast
and the end date. I also included a link to the implementation, since
this is the main relevant thing for a policy RFC. Voting will close a
little over 14 days from now. I have specified some buffer room to
account for “mail delivery delay”.

I will make sure to add a link to the archives of the voting thread as
soon as I see it appear in the archives.

Best regards
Tim Düsterhus

May I ask, as a follow-up task, to add some kind of copy/pastable templates to the rfc:howto (https://wiki.php.net/rfc/howto)? For example, what information needs to be sent in major/minor/editorial changes? Do you need to declare which type of change it is and its effect, or is it simply assumed everyone knows?

I’m just asking because the proceedure isn’t clear (I was trying to follow it):

Major and minor changes MUST be announced in the official discussion thread, either in a dedicated email summarizing a list of changes or in a reply to another email that clearly indicates that changes to the RFC text have been made in response to that email.

Does this mean “A major change has been made” as in literally announcing the type of change, or just that the change must be announced?

— Rob

3

Hi

On 11/9/25 16:15, Rob Landers wrote:

May I ask, as a follow-up task, to add some kind of copy/pastable templates to the rfc:howto (PHP: rfc:howto)? For example, what information needs to be sent in major/minor/editorial changes? Do you need to declare which type of change it is and its effect, or is it simply assumed everyone knows?

I had planned to make some changes to the template at PHP: rfc:template, but not the How To. I can have a look at the How To as well.

_Major and minor changes MUST be announced in the official discussion thread, either in a dedicated email summarizing a list of changes or in a reply to another email that clearly indicates that changes to the RFC text have been made in response to that email._

Does this mean "A major change has been made" as in literally announcing the type of change, or just that the change must be announced?

The latter. The required email is intended as an invitation to the participants to have another look after the RFC authors believe that the changes to the RFC are complete (for now) and then to discuss the latest changes.

The type of change (Major / Minor) should be clear for the majority of changes, but spelling it out explicitly can't hurt - if only for yourself to keep track of things. Keeping a changelog in the RFC will help as well.

Best regards
Tim Düsterhus

4

Hi Tim, everyone,

Hi

I just opened voting on the “Clarify discussion and voting period rules”
RFC. Please find the following resources:

The RFC contains a single primary vote requiring a 2/3 majority. Voting
will close 2025-11-20 09:30:00 UTC.

As during the discussion, I’d like to explicitly spell out some of the
things that I took into account.

It is now 2025-11-06 08:54 UTC (and will be a little later when I
actually hit send).

A little more than 14 days have passed since the last major change. A
little more than 2 days have passed since the Intent to Vote
announcement. Both is strictly within the proposed rules. The RFC was
not inactive, since the last email was my Major Change announcement,
which happened less than 42 days ago.

This email contains all the necessary information, namely the link to
the RFC text, Discussion Thread, a list of the number of votes to cast
and the end date. I also included a link to the implementation, since
this is the main relevant thing for a policy RFC. Voting will close a
little over 14 days from now. I have specified some buffer room to
account for “mail delivery delay”.

I will make sure to add a link to the archives of the voting thread as
soon as I see it appear in the archives.

After chatting with a few, I decided to vote against the RFC.

I do appreciate the effort to formalize our unwritten rules.
Yet I’d summarize my vote as: too many MUSTs, not enough SHOULDs in the proposed policy.
I do think it’s important to clarify the rules for occasional contributors, and MUSTs make things more annoying to me, not smoother.
Also, despite the intro of the RFC, it goes past just clarifying current rules: it adds MUSTs on things we are fine agreeing to case by case at the moment.
I wish common sense still remains our main approach, and the RFC as proposed makes me feel we go into more bureaucracy.
And to me, bureaucratie makes things smoother only for the experts of its own rules.
Thus my vote.

Cheers,
Nicolas

5

Hey,

···

On 15.11.2025 10:19:29, Nicolas Grekas wrote:

Hi Tim, everyone,

Hi

I just opened voting on the “Clarify discussion and voting period rules”
RFC. Please find the following resources:

The RFC contains a single primary vote requiring a 2/3 majority. Voting
will close 2025-11-20 09:30:00 UTC.

As during the discussion, I’d like to explicitly spell out some of the
things that I took into account.

It is now 2025-11-06 08:54 UTC (and will be a little later when I
actually hit send).

A little more than 14 days have passed since the last major change. A
little more than 2 days have passed since the Intent to Vote
announcement. Both is strictly within the proposed rules. The RFC was
not inactive, since the last email was my Major Change announcement,
which happened less than 42 days ago.

This email contains all the necessary information, namely the link to
the RFC text, Discussion Thread, a list of the number of votes to cast
and the end date. I also included a link to the implementation, since
this is the main relevant thing for a policy RFC. Voting will close a
little over 14 days from now. I have specified some buffer room to
account for “mail delivery delay”.

I will make sure to add a link to the archives of the voting thread as
soon as I see it appear in the archives.

After chatting with a few, I decided to vote against the RFC.

I do appreciate the effort to formalize our unwritten rules.
Yet I’d summarize my vote as: too many MUSTs, not enough SHOULDs in the proposed policy.
I do think it’s important to clarify the rules for occasional contributors, and MUSTs make things more annoying to me, not smoother.
Also, despite the intro of the RFC, it goes past just clarifying current rules: it adds MUSTs on things we are fine agreeing to case by case at the moment.
I wish common sense still remains our main approach, and the RFC as proposed makes me feel we go into more bureaucracy.
And to me, bureaucratie makes things smoother only for the experts of its own rules.
Thus my vote.

Cheers,
Nicolas

I completely agree with Nicolas’ sentiment. The RFC process MUST be mostly guidelines, with few hard rules which govern the fundamental requirements.

For example, you SHOULD not make changes to RFCs during voting periods. But you MAY make them. For purposes of clarification, for changing a detail which was pointed out very late, but is not material to the overall RFC.
Even when it would actually qualify as a “Major change” according to your definition, but actually is very minor.
As a made-up example, if a pattern matching RFC would discuss the order of destruction of the arguments provided to the pattern in its RFC. And it turns out, for someone who played around with the implementation, that the RFC text did not fully match the implementation. It’s a detail, but still qualifies as semantics. And it’s unlikely to change the minds of the voters. This would be a textbook example for me, where a RFC text SHOULD be adjusted, the list notified, but the vote be maintained, and not cancelled, nor a grace period observed. If people then object to the non-cancellation, because they consider it material enough, then the vote MUST be cancelled.

In short - not all “major change” is actually major.

Same for “minor changes” - your definition calls every single addition of an example or clarifications as minor change. Are you intending to discourage RFC maintainers of adding new examples shortly before a vote, when internals participants point something not fully explained? So that the vote just may happen when the RFC maintainer intended it, instead of - as you mandate - a week later. Sounds nonsense to me.
Instead, similar to changes during voting period, make it a judgement call for the maintainer, and allow voters to request an extension of the discussion period, if they disagree.

Also I don’t like the requirement, that the RFC text shall be immutable, except for the errata section, in particular before a GA release. In particular minor RFC implementation details sometimes do change, e.g. due to conflicting semantics, implementation difficulties with specific edge cases etc. You say it’s for the errata section. But I disagree.
The RFC text should mirror, what is being introduced to the language ultimately in a GA, also as a proper reference for later readers including documentators, and the errata section should tell what the prior state was (in case you are interested in knowing the voted on version, essentially).

Or the holiday requirement is not flexible enough. Why not say “MUST NOT both, start and end, within …” so that you may start or end a voting period there, but it will be open for at least a bit outside of the window, too.

Thanks,

Bob

6

Hi

Am 2025-11-06 10:02, schrieb Tim Düsterhus:

I just opened voting on the "Clarify discussion and voting period rules" RFC. Please find the following resources:

- RFC Text: PHP: rfc:rfc_discussion_and_vote
- Implementation PR: Clarify discussion and voting period rules by TimWolla · Pull Request #23 · php/policies · GitHub
- Discussion Thread: php.internals: [RFC] Clarify discussion and voting period rules

The RFC contains a single primary vote requiring a 2/3 majority. Voting will close 2025-11-20 09:30:00 UTC.

The RFC has been accepted accepted with 24 (Yes) to 6 (No) votes (80%) and 1 Abstention. Jakub already merged the PR and I'll make the adjustment to the RFC template and how-to pages later today and then report back once more.

Best regards
Tim Düsterhus

7

Hi

On 11/20/25 11:03, Tim Düsterhus wrote:

The RFC has been accepted accepted with 24 (Yes) to 6 (No) votes (80%)
and 1 Abstention. Jakub already merged the PR and I'll make the
adjustment to the RFC template and how-to pages later today and then
report back once more.

Busy day with the PHP 8.5 release, but I made the changes now:

and

Please let me know if you think I missed anything important to adjust (or update yourself and keep the list in the loop).

Best regards
Tim Düsterhus

8

Hi

Thank you for explaining your position. The RFC has been accepted in the mean time, but I wanted to nevertheless comment on your email.

On 11/15/25 10:19, Nicolas Grekas wrote:

I wish common sense still remains our main approach, and the RFC as
proposed makes me feel we go into more bureaucracy.
And to me, bureaucratie makes things smoother only for the experts of its
own rules.

I feel exactly the opposite. I feel that having clear rules - that are followed by every contributor - make it easier for less-experienced contributors to follow the same standard. Instead of needing to learn about expectations by reading up on older RFCs, there is a clear document that they can refer to.

In my opinion most of the policy can be summarized as: “Take your time to make sure to build the best possible RFC together with the other participants”. The formalization of the Cooldown Period is probably the most significant thing that has newly been written down and I don't think it's a particularly complicated rule to follow.

The other things, like keeping a Changelog, is something that is easy to fix when someone forgets. Someone will notice and send a reminder for you to update the changelog. Or if something is missing from the voting announcement mail, someone else can add the missing information in a reply.

A SHOULD instead of a MUST however just invites discussion of whether or not it is okay to ignore the rule in any specific case, which will just add noise to the list and is what a policy is intended to avoid.

Best regards
Tim Düsterhus