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

[youkidearitai]

2025年10月5日(日) 10:53 Nick <php@nicksdot.dev>:

On 4. Oct 2025, at 16:02, youkidearitai <youkidearitai@gmail.com> wrote:

2025年10月3日(金) 23:10 Tim Düsterhus <tim@bastelstu.be>:

Hi

Am 2025-09-29 14:13, schrieb youkidearitai:

Anyway, I thought about this topic few days.
As long as there are people who don't take part in the discussion in
"Under Discussion" phase, I'll say no to this topic.

I was concerned that "Clarify " would put people who are not native
English at a disadvantage (I'm writing use Google translate too).
This will not clear the concerns.
(However, I don't have grant for vote an RFC)

First, we must join to discussion in "Under Discussion" phase.

As mentioned in my previous email, I believe there is a
misunderstanding. My RFC is not intended to make it harder to make RFCs
or to put folks who are not native speakers of English at a disadvantage
(I am not a native speaker myself). It is formalizing some rules around
the length of the discussion period to ensure there is sufficient time
for folks to provide feedback after every change made.

Looking at your RFC specifically, you would have needed to do the
following things differently:

- You made minor clarification changes on 2025-06-27. You would have
needed to mention them on the list and wait for 7 days before starting
the initial vote.
- Similarly for the revision, you removed the `$strength` parameter on
2025-07-15. This was a major change which you announced on the list, but
you would have needed to wait 14 days before starting the vote, you only
waited 10 days.
- And on 2025-07-22 there was some clarification, which was not
announced on the list.
- You would have needed to add a link to the mailing list discussion to
the RFC itself.

Everything else was already compliant from what I see. I think you can
see how “announcing changes and waiting a little” is not significantly
changing or complicating the RFC process.

Best regards
Tim Düsterhus

I can't be convinced about this matter.
It was a terrible pressure to be suddenly voting with no one to give
us advice on what we should have an under Discussion discussion.
This only appears to justify the mistakes they have made.

This will put me at a major disadvantage.
I couldn't agree with your reply. I have to say that it's NO after all.

Regards
Yuya

--
---------------------------
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- youkidearitai (tekimen) · GitHub
——————————————

Hey Yuya.

Follow up on what we communicated off-list. I will hopefully can summarise what Tim means in plain English.

Tim wrote:

If you realized less than 2 days into the vote that you didn't properly take the feedback into account and then *do* take the feedback into account, I'd consider this a success story rather than a failure.

In fact we had just that for PHP 8.5. The “Add locale for case insensitive grapheme functions” RFC had gotten little feedback during the discussion and during the vote, Derick mentioned that the proposal was insufficient to make an educated decision. The vote was then canceled and later (successfully) restarted:

Tim is not targeting your RFC negatively.
Tim is using your RFC to show when canceling a vote can be good.
Tim is supporting what you did.
Tim is not planning for the future to disallow what you did.
Tim is confirming what you did should officially be allowed.

Tim wrote:

My policy RFC is explicitly saying that canceling the vote in cases like this is allowed.

Tim again confirms that what you did should be officially allowed.

Tim wrote:

Looking at your RFC specifically, you would have needed to do the following things differently:

- You made minor clarification changes on 2025-06-27. You would have needed to mention them on the list and wait for 7 days before starting the initial vote.
- Similarly for the revision, you removed the `$strength` parameter on 2025-07-15. This was a major change which you announced on the list, but you would have needed to wait 14 days before starting the vote, you only waited 10 days.
- And on 2025-07-22 there was some clarification, which was not announced on the list.
- You would have needed to add a link to the mailing list discussion to the RFC itself.

Everything else was already compliant from what I see. I think you can see how “announcing changes and waiting a little” is not significantly changing or complicating the RFC process.

Tim is not saying you did wrong.
Tim is showing examples for what will be different in the future (if this RFC is accepted)
Tim is telling you that your RFC handling was good.
Tim is showing that your RFC handling would not be much different in the future (if this RFC is accepted)

--

I hope this helps to also solve the misunderstanding on-list.

Cheers,
Nick

Hi, Tim, Nick

I sincerely apologize.
I am misunderstanding Tim's RFC.

I realized this would not interfere with anyone.
Sorry for the misunderstanding. I take that back what I said "NO".
It's called "YES".

Regards
Yuya

--
---------------------------
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- youkidearitai (tekimen) · GitHub
-----------------------------

[Nick]

On 5. Oct 2025, at 09:21, youkidearitai <youkidearitai@gmail.com> wrote:

2025年10月5日(日) 10:53 Nick <php@nicksdot.dev>:

On 4. Oct 2025, at 16:02, youkidearitai <youkidearitai@gmail.com> wrote:

2025年10月3日(金) 23:10 Tim Düsterhus <tim@bastelstu.be>:

Hi

Am 2025-09-29 14:13, schrieb youkidearitai:

Anyway, I thought about this topic few days.
As long as there are people who don't take part in the discussion in
"Under Discussion" phase, I'll say no to this topic.

I was concerned that "Clarify " would put people who are not native
English at a disadvantage (I'm writing use Google translate too).
This will not clear the concerns.
(However, I don't have grant for vote an RFC)

First, we must join to discussion in "Under Discussion" phase.

As mentioned in my previous email, I believe there is a
misunderstanding. My RFC is not intended to make it harder to make RFCs
or to put folks who are not native speakers of English at a disadvantage
(I am not a native speaker myself). It is formalizing some rules around
the length of the discussion period to ensure there is sufficient time
for folks to provide feedback after every change made.

Looking at your RFC specifically, you would have needed to do the
following things differently:

- You made minor clarification changes on 2025-06-27. You would have
needed to mention them on the list and wait for 7 days before starting
the initial vote.
- Similarly for the revision, you removed the `$strength` parameter on
2025-07-15. This was a major change which you announced on the list, but
you would have needed to wait 14 days before starting the vote, you only
waited 10 days.
- And on 2025-07-22 there was some clarification, which was not
announced on the list.
- You would have needed to add a link to the mailing list discussion to
the RFC itself.

Everything else was already compliant from what I see. I think you can
see how “announcing changes and waiting a little” is not significantly
changing or complicating the RFC process.

Best regards
Tim Düsterhus

I can't be convinced about this matter.
It was a terrible pressure to be suddenly voting with no one to give
us advice on what we should have an under Discussion discussion.
This only appears to justify the mistakes they have made.

This will put me at a major disadvantage.
I couldn't agree with your reply. I have to say that it's NO after all.

Regards
Yuya

--
---------------------------
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- youkidearitai (tekimen) · GitHub
——————————————

Hey Yuya.

Follow up on what we communicated off-list. I will hopefully can summarise what Tim means in plain English.

Tim wrote:

If you realized less than 2 days into the vote that you didn't properly take the feedback into account and then *do* take the feedback into account, I'd consider this a success story rather than a failure.

In fact we had just that for PHP 8.5. The “Add locale for case insensitive grapheme functions” RFC had gotten little feedback during the discussion and during the vote, Derick mentioned that the proposal was insufficient to make an educated decision. The vote was then canceled and later (successfully) restarted:

Tim is not targeting your RFC negatively.
Tim is using your RFC to show when canceling a vote can be good.
Tim is supporting what you did.
Tim is not planning for the future to disallow what you did.
Tim is confirming what you did should officially be allowed.

Tim wrote:

My policy RFC is explicitly saying that canceling the vote in cases like this is allowed.

Tim again confirms that what you did should be officially allowed.

Tim wrote:

Looking at your RFC specifically, you would have needed to do the following things differently:

- You made minor clarification changes on 2025-06-27. You would have needed to mention them on the list and wait for 7 days before starting the initial vote.
- Similarly for the revision, you removed the `$strength` parameter on 2025-07-15. This was a major change which you announced on the list, but you would have needed to wait 14 days before starting the vote, you only waited 10 days.
- And on 2025-07-22 there was some clarification, which was not announced on the list.
- You would have needed to add a link to the mailing list discussion to the RFC itself.

Everything else was already compliant from what I see. I think you can see how “announcing changes and waiting a little” is not significantly changing or complicating the RFC process.

Tim is not saying you did wrong.
Tim is showing examples for what will be different in the future (if this RFC is accepted)
Tim is telling you that your RFC handling was good.
Tim is showing that your RFC handling would not be much different in the future (if this RFC is accepted)

--

I hope this helps to also solve the misunderstanding on-list.

Cheers,
Nick

Hi, Tim, Nick

I sincerely apologize.
I am misunderstanding Tim's RFC.

I realized this would not interfere with anyone.
Sorry for the misunderstanding. I take that back what I said "NO".
It's called "YES".

Regards
Yuya

--
---------------------------
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- youkidearitai (tekimen) · GitHub
——————————————

Lovely. Keep up the good work.

[Tim_Dusterhus]

Hi

On 10/5/25 04:21, youkidearitai wrote:

I sincerely apologize.
I am misunderstanding Tim's RFC.

Apology accepted. I am happy that Nick was able to clear up the misunderstanding.

Best regards
Tim Düsterhus

[ilutov]

Hi Tim

On Wed, Sep 24, 2025 at 9:09 AM Tim Düsterhus <tim@bastelstu.be> wrote:

Hi

Am 2025-09-19 10:55, schrieb Tim Düsterhus:
>> Please find the RFC at:
>> PHP: 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 more than 7 days before the vote is officially opened (“Intent to Vote lifetime”).

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 avoided 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 severe issues with the RFC.

I don't think this restriction is necessary. Tim mentioned to me
off-list it was motivated by this message:
[RFC] Clarify discussion and voting period rules - Externals. 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 could have simply declared “an issue” and updated it with their 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

[Tim_Dusterhus]

Hi

Am 2025-10-09 19:54, schrieb Ilija Tovilo:

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.

Thank you.

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 more than 7 days before the vote is officially opened (“Intent to Vote lifetime”).

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.

If the “Intent to Vote” causes the discussion to restart in a significant fashion, then IMO the RFC was not actually ready to go to voting yet. Expiring the Intent to Vote and requiring a new one after the new discussion is resolved is the intended behavior. Historically in most cases the Intent to Vote was already “I think I'm done, I plan to start the RFC in 2 days” and then that either happens, folks provide feedback or they at least say “Please give me another day or two, super busy right now”. So I don't expect the 7-day limit to become relevant in practice.

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 avoided 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.

If it's *obviously* contradicting, I would consider it a typo fix. If it's not obvious, folks that only read the examples (which I expect to be a significant amount, since examples are much more approachable) might be misled and might want to change their vote as a result of that. Thus this type of fixes to the examples should not just happen casually.

As an example, during my review of the current PFA RFC, I found several examples that contradicted my understanding of the “prose semantics”. In some cases the example was incorrect, but in other cases the “prose” was incorrect or unclear and the example correctly showcased what was intended to be proposed. It's thus not easy to say that the prose is authoritative.

The voting period MAY be canceled within the first 2 days in case of severe issues with the RFC.

I don't think this restriction is necessary. Tim mentioned to me
off-list it was motivated by this message:
[RFC] Clarify discussion and voting period rules - Externals. 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 could have simply declared “an issue” and updated it with their 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.

Does anyone except Ilija have an opinion on this?

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).

That makes sense to me. I don't think the proposed policy text disallows this, but I'll look if I can spell it out more explicitly that this is encouraged.

Best regards
Tim Düsterhus

[Tim_Dusterhus]

Hi

Am 2025-10-17 10:40, schrieb Tim Düsterhus:

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).

That makes sense to me. I don't think the proposed policy text disallows this, but I'll look if I can spell it out more explicitly that this is encouraged.

I have now made the change: Clarify discussion and voting period rules by TimWolla · Pull Request #23 · php/policies · GitHub

Given the previous reasoning of “the policy doesn't disallow this” and all the Errata policy being a SHOULD (including the new bits), I'm treating this change as a Minor Change.

Best regards
Tim Düsterhus

[Crell]

On Fri, Oct 17, 2025, at 3:40 AM, Tim Düsterhus wrote:

The voting period MAY be canceled within the first 2 days in case of
severe issues with the RFC.

I don't think this restriction is necessary. Tim mentioned to me
off-list it was motivated by this message:
[RFC] Clarify discussion and voting period rules - Externals. 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
could have simply declared “an issue” and updated it with their
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.

Does anyone except Ilija have an opinion on this?

AIUI, the purpose of not allowing cancellation of the vote at any time is to avoid "it's about to fail so I'll pull it, to avoid the 6 month cooldown before I can resubmit" situations. I'm not sure how big of a concern that is.

Personally I'd be fine allowing a cancellation up to the 1 week mark; that gives a bit more time to hear if "I'd vote yes except for this one small issue" is a significant enough constituency that it's worth short-circuiting the process without delaying another release cycle.

--Larry Garfield

[Tim_Dusterhus]

Hi

Am 2025-10-22 00:26, schrieb Larry Garfield:

AIUI, the purpose of not allowing cancellation of the vote at any time is to avoid "it's about to fail so I'll pull it, to avoid the 6 month cooldown before I can resubmit" situations. I'm not sure how big of a concern that is.

Personally I'd be fine allowing a cancellation up to the 1 week mark; that gives a bit more time to hear if "I'd vote yes except for this one small issue" is a significant enough constituency that it's worth short-circuiting the process without delaying another release cycle.

Okay, I find 1 week to be a reasonable compromise and have just made the change to the RFC.

I am treating this change as a major change. Given that the discussion has effectively come to an end, I expect to start the vote shortly after the two weeks have passed. I'll send a separate official Intent to Vote at a later point.

Best regards
Tim Düsterhus

[Tim_Dusterhus]

Hi

Am 2025-10-23 09:37, schrieb Tim Düsterhus:

I am treating this change as a major change. Given that the discussion has effectively come to an end, I expect to start the vote shortly after the two weeks have passed. I'll send a separate official Intent to Vote at a later point.

The two weeks will have passed on Thursday and there were no further comments. I thus plan to start the vote on Thursday. I have just filled in the final commit hash into the voting widget (which I'm not treating as a major change, since policy RFCs are a little different than regular RFCs in that the PR is the main artifact).

Best regards
Tim Düsterhus