[VOTE] Clarify discussion and voting period rules

Hi

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 had planned to make some changes to the template at
https://wiki.php.net/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

Hey,

Hi Tim, everyone,

Hi

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

- RFC Text: https://wiki.php.net/rfc/rfc_discussion_and_vote
- Implementation PR: https://github.com/php/policies/pull/23
- Discussion Thread: https://news-web.php.net/php.internals/128594

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: https://news-web.php.net/php.internals/128921
- The Intent to Vote announcement was sent on 2025-11-04 08:45:24
UTC:
https://news-web.php.net/php.internals/129063
- 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.

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