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

Mailing Lists php.internals
21

On Fri, Sep 5, 2025, at 12:22, Tim Düsterhus wrote:

Hi

Am 2025-09-04 20:17, schrieb Rob Landers:

Specifically “Other RFCs” (i.e. RFCs that do not touch the language,
which is not actually defined) “might” (this probably should read
“may”)
use a “smaller timeframe” that “should be at least a week” (i.e. it
may
also be 2 hours). In other words, that policy is completely useless to
resolve any cases of disagreement, since it allows basically anything.

So, someone could create an RFC, saying “Jo ElePHant, III” is
“President of PHP”, set the voting period for exactly one minute, vote
on it themselves, and close the vote, and whomever “Jo ElePHant, III”
is, would have to be the President of PHP before the announcement email
is even delivered to the entire list?

That is my understanding of the current policy, yes.

:sob:

Somehow I doubt this would actually fly, despite “maybe, technically”,
being within the rules.

Sure. It would also possible to follow-up with a new “proper” RFC that
reverses the previous decision. You were using an extreme example, but
we a case in PHP 8.5 where the discussion period arguably was cut short:
https://externals.io/message/128040#128272

I think the more you make a policy pedantic, the easier it is to play
pedantic games. I had a couple of hours to sit on the train and think
through some loopholes in the current proposed text:

  1. The 336 hours is oddly specifc. It also begs the question: “what
    about leap seconds?” Could someone cause an entire revote simply by
    pointing out that the vote closed one second earlier than 336 hours
    because one of those hours had one less second? Does it matter? Perhaps
    saying “~336 hours” to drive the intent home without saying “exactly”
    that amount of time?

An hour is well-defined to be 3600 seconds. Leap seconds are a concept
of “date and time”, but do not affect how much time has actually passed.
After 2035 there will be no more leap seconds and given the slowing of
Earth’s rotation it seems unlikely to have any more leap second. In any
case it is easy for an RFC author to completely bypass this question by
treating the specified lengths of time as minimums, which is likely to
implicitly happen anyways.

The widget requires you to specify a datetime that it ends on, not a duration. Meaning the time between the two week dates is not guaranteed to always be exactly 336 hours, even in UTC. If there is a leap second, it would be 335:59:59 hours between the two dates, possibly unbeknownst to the person setting up the voting widget. Someone wanting to invalidate the vote (or whatever the penalty is), could then do so and be within their rights.

  1. Just about any change could be construed as an “obvious typo” or
    “editorializing” A stronger definition could be “any change that
    clarifies but does not alter the meaning (e.g. “frrm” → “from” but not
    “form” → “from”), while changes that affect APIs, semantics, or
    options are never typos”. Even then, someone could just create a stub
    and simply argue that all their edits are clarifying the stub… so
    this one will be tricky.

I believe this is sufficiently handled by the “when in doubt treat it as
a more significant change” and the list of examples of what constitutes
a major or minor change. The proposed policy specifically says that
“clarification” is a minor change and that anything that would lead to a
change in implementation is a major change.

Right, but who is doing the doubting? There isn’t a defined arbiter, thus it can be a battle of the wills: someone on the list claiming it is a significant change vs. (potentially multiple) authors who disagree. Someone needs to be able to say “this is significant” and make that decision binding.

  1. Forbidding starting/ending on Dec 17->Jan 10 will probably
    backfire. It would behoove someone to schedule a voting start on Dec
    16, so that it would end on Jan 11. Albeit, that is longer than 2
    weeks, but it’s shorter than waiting until Jan 11 to start a vote…
    arguably, this is probably worse than what the rule intends to solve.
    If the concern is holiday churn (heh, uninitentional rhyming), it might
    be better to forbid starting during that period, but let existing
    votes play out as normal (and maybe picking a sooner date).

Starting on December 16 and ending on January 11 would be fine for me.
I’ve intentionally added some buffer space so that anyone interested in
participating in the RFC process should find the time to cast their vote
after they followed the RFC discussion and thus had the opportunity to
make up their mind. Besides “New Year’s” and “Christmas”, I’ve
specifically also accounted for Eastern Christianity Christmas (relevant
for Russia) which is on January 7th.

Interesting. It’s probably fine then. I just wanted to point out that there could be unforseen consequences with people rushing to get to a vote before that period, resulting in less quality RFCs vs. waiting.

  1. The official start and threading is ambiguous. For example, I can
    add a coauthor on my RFC. Then “announce” the RFC by both authors but
    only have discussions in the later thread. I could move to a vote after
    two weeks, no matter what is happening in another “unofficial” thread.

I’m afraid I don’t understand what you are trying to say here.

It said that an RFC timing is bound to a thread starting with a specific subject. Both authors could create two separate threads, one that is “unofficial” but looks official, and the other “official” thread that no conversation happens on. Since no conversation has occurred on the “official” thread, they could just start a vote after two weeks and technically not violate the rules (assuming they made no significant changes to the RFC). We see this often where the pre-discussion thread outlives the official announcement thread, for example; and they’re not even being malicious. In this case, the RFC author wouldn’t be bound by the cooloff periods at all.

  1. It says that you can’t add or change a voting widget, but you can
    remove them freely without triggering a vote reset.

Removing is the most extreme form of changing one, but I can certainly
spell that out explicitly.

  1. It might be a good idea to add “all durations are measured in UTC
    calendar time, ignoring leap seconds”. One could argue that announcing
    the vote at 11:59:59 Monday and starting the vote at 00:00:01 Wednesday
    would satisfy the 2 day/48 hour rule by arguing time zone shenanigans.

The hour-based definition is already independent of any timezones.

Vote starts are based on a specific time, usually with the local time of the email in the headers. It doesn’t explicitely and unambiguously say these are durations in a specific timezone, but implies it. One extreme example would be to say that 2 days had passed somewhere in the universe with a different flow of time relative to our local space.

  1. If a vote ends at 15:09, does it actually ends at 15:09:00, or will
    votes be accepted until 15:09:59.99?

I’m happy to clarify this in the policy. Similarly to deadlines in the
real world this would be understood “until, but not including”, i.e. as
long as the clock doesn’t show 15:09.

  1. vote extension hack: can someone change a vote end-date after the
    vote has already started? Thus if the results are unfavorible, can I
    simply just extend the voting period until I get the results I want,
    literally increasing it by 24 hours every day until it passes by simply
    stating “I am still on holiday”?

No. The end date must clearly be specified in the email announcing the
vote. You are free to select a longer interval right away, but once the
vote started, the decision is locked in. I can spell it out more
explicitly that the RFC (including the voting rules) may no longer
change once the vote started.

The new rules could allow some creative people to bypass the cooldown
period altogether:

  1. Someone could create an empty RFC, and announce it. Then “clarify”
    and “editorialize” the RFC (easier to do with a coauthor to back you
    up) minutes before the two weeks elapse, then call a vote, with most
    people having long dismissed the empty RFC as junk.

I believe I answered that with bullet point (2) above.

  1. You could simply create a v2 of an RFC minutes/days after the
    failed vote and go straight to a vote; claiming the cooldown started
    from the original RFC.

I don’t see how that would be possible even with an intentionally
“malicious” reading of the policy. The policy specifies that the
discussion period of an RFC starts with the official RFC discussion
thread matching the title of the RFC and linking the Wiki page. Thus any
existing discussion clearly is not applicable to a newly created RFC.

Best regards
Tim Düsterhus

— Rob

22

On Wed, Sep 3, 2025, at 4:09 PM, Tim Düsterhus wrote:

The language for the "extending the discussion period" paragraph is highly clumsy and confusing. The existence of the last sentence to clarify it is evidence of that. I would recommend rewriting it. (I can offer suggestions if you're open to it.)

I am open to suggestions, yes. Not being a native speaker makes it easy
to write stuff that makes sense to me, but are confusing to folks that
actually understand the language :slight_smile:

Really, though... what is actually being proposed, and is not actually a widespread convention right now, is a policy of "the vote may start two weeks after the last substantive change." For some definition of "substantive." If that is the intent, it should just say that. And we should discuss directly if we actually want that requirement.

That would be an accurate summary of what that part of the policy is
trying to codify, yes.

Proposed language, to turn the whole thing around:

-----

An RFC author MAY start a vote at any time, provided that:

* It has been at least two weeks since the last major change.
* It has been at least one week since the last minor change.
* There has been at least one post of any kind in the discussion thread within the last 6 weeks.
* The author has posted an intent to open the vote at least 48 hours prior. (This post is the only one that does not count toward the "last 6 weeks" rule.)
* There is no ongoing relevant and substantive discussion still happening in the thread. The author may determine what qualifies as relevant and substantive, but SHOULD be liberal in interpreting that.

-----

(The final point is to help avoid the hecklers veto problem. If people are just talking in circles, or there's a tangent discussion still going that doesn't matter to this RFC, those shouldn't count.

I am also still not 100% convinced this level of formal-time-extension is necessary. There are always RFCs introduced late in the cycle that run up into freeze. That will happen no matter what we do; they may even be going for a few months before getting there. But if consensus is finally reached 13 days before the last day to start a vote to make the freeze deadline, and everyone seemingly agrees with the final change, it seems silly to say "whelp, sorry, you should have posted the last update 12 hours earlier, now we all have to wait an extra year for the thing we finally agreed on."

And I would say that this matches the lived reality: For most
(successful) RFCs the author makes some changes, announces them on the
list and then ask for feedback (e.g. from the person who originally
suggested the changes or who pointed out the mistake), which can easily
take a day or two to arrive. This then often sparks additional
discussion that takes a few more days to settle down due to varying
schedules and timezones. At this point a week easily passed.

I would also say that it matches the spirit of a “minimum discussion
period”. It does not appear very useful that it is technically allowed
by policy to replace the entire RFC text 10 minutes before the vote.
Something something RFC of Theseus.

In cases where the actual proposal (rather than e.g. the examples)
repeatedly changes over the course of the discussion generally indicates
some severe problem or oversight with the RFC. It would often be more
appropriate for the RFC author to go back to the drawing board,
consulting with some close advisors to figure out how to fix these
problems rather than discussing all those details on the list.

That often happens, but then the revisions are put forward in the same thread. That's process-wise identical.

That section is intentionally using the “SHOULD NOT” indicator, to avoid
folks being able to filibuster an RFC. It also intentionally used the
word “new” in front of “discussion points” to indicate that repeating
something from before (something that most likely already was rejected
by the RFC author) does not constitute a new discussion point. The
intention is to encourage RFC authors to give suggestions sufficient
deliberation (and ideally a response), even if it comes in after the
voting announcement.

I'm happy to rephrase if you have any suggestions.

I believe my bullet point list above encapsulates this expectation.

Regarding the time precision debate elsewhere in the thread: For most things, I don't think we need to get hung up on exact timing. If it's been 6 days, 23 hours, and 49 minutes since the last update to an RFC, and there's been no discussion in that time, and the last post was everyone agreeing that the last change is good... Then it's kinda stupid to get hung up on "you didn't wait exactly 11 minutes" and invalidate a vote that is clearly ready. If we were a more protocol-and-process oriented project with actual leadership, then more precision might make sense. But PHP is not that, for better or worse: It's a bunch of people arguing and coming to rough consensus in the messiest way possible. Fussing about a minute here or there is not helpful.

The one place I think it would matter is when the vote closes, since that's a hard-cutoff for someone to vote or change a vote. For that, IMO the best solution is technical: Update the voting widget to both have an auto-close time, and show the start and auto-close time on the wiki page. The vote closes when the widget says it does. Presumably it would be easy for it to default to the exact same time as the start stamp, and then... I don't care about leap seconds or daylight savings time. It ends in ~2 weeks, automatically, and the exact time is right there on the page. Plan accordingly.

Then all the faffing about with date-and-time edge cases goes away and we can move on with life.

--Larry Garfield

23

Hi

Am 2025-09-05 18:58, schrieb Larry Garfield:

Proposed language, to turn the whole thing around:

-----

An RFC author MAY start a vote at any time, provided that:

* It has been at least two weeks since the last major change.
* It has been at least one week since the last minor change.
* There has been at least one post of any kind in the discussion thread within the last 6 weeks.
* The author has posted an intent to open the vote at least 48 hours prior. (This post is the only one that does not count toward the "last 6 weeks" rule.)
* There is no ongoing relevant and substantive discussion still happening in the thread. The author may determine what qualifies as relevant and substantive, but SHOULD be liberal in interpreting that.

-----

Thank you. That would likely require breaking up the existing structure oh “Discussion Phase” and “Voting Phase” a little to incorporate this cleanly. It would basically make the entire “Discussion Phase” section obsolete, which is quite large of a change that I'll need to think about a little more.

Perhaps the latest changes already make the language a little less awkward?

(The final point is to help avoid the hecklers veto problem. If people are just talking in circles, or there's a tangent discussion still going that doesn't matter to this RFC, those shouldn't count.

I have just incorporated a suggestion from Ilija to soften the language a little: Clarify discussion and voting period rules by TimWolla · Pull Request #23 · php/policies · GitHub

I am also still not 100% convinced this level of formal-time-extension is necessary. There are always RFCs introduced late in the cycle that run up into freeze. That will happen no matter what we do; they may even be going for a few months before getting there. But if consensus is finally reached 13 days before the last day to start a vote to make the freeze deadline, and everyone seemingly agrees with the final change, it seems silly to say "whelp, sorry, you should have posted the last update 12 hours earlier, now we all have to wait an extra year for the thing we finally agreed on."

I believe a clear and objectively measurable rules are necessary to treat everyone fairly. If 13.5 days are acceptable, are 13 days also acceptable? What about 12.5 days? Where do we draw the line?

Frankly it is unlikely to be incidental that an RFC with “a few months of discussion” (lets say 4 months, so 17 weeks) suddenly gets finalized less than 2 weeks before the feature freeze. It's much more likely that an author tried to meet a deadline at the expense of quality, which also raises the likelihood of finding unanticipated issues during implementation. The latter is already happening with RFCs that are finalized well before the freeze, your pipe operator would be the latest example that comes to mind.

And I would say that this matches the lived reality: For most
(successful) RFCs the author makes some changes, announces them on the
list and then ask for feedback (e.g. from the person who originally
suggested the changes or who pointed out the mistake), which can easily
take a day or two to arrive. This then often sparks additional
discussion that takes a few more days to settle down due to varying
schedules and timezones. At this point a week easily passed.

I would also say that it matches the spirit of a “minimum discussion
period”. It does not appear very useful that it is technically allowed
by policy to replace the entire RFC text 10 minutes before the vote.
Something something RFC of Theseus.

In cases where the actual proposal (rather than e.g. the examples)
repeatedly changes over the course of the discussion generally indicates
some severe problem or oversight with the RFC. It would often be more
appropriate for the RFC author to go back to the drawing board,
consulting with some close advisors to figure out how to fix these
problems rather than discussing all those details on the list.

That often happens, but then the revisions are put forward in the same thread. That's process-wise identical.

Sorry, I don't follow.

Regarding the time precision debate elsewhere in the thread: For most things, I don't think we need to get hung up on exact timing. If it's been 6 days, 23 hours, and 49 minutes since the last update to an RFC, and there's been no discussion in that time, and the last post was everyone agreeing that the last change is good... Then it's kinda stupid to get hung up on "you didn't wait exactly 11 minutes" and invalidate a vote that is clearly ready. If we were a more protocol-and-process oriented project with actual leadership, then more precision might make sense. But PHP is not that, for better or worse: It's a bunch of people arguing and coming to rough consensus in the messiest way possible. Fussing about a minute here or there is not helpful.

See above. Also: Decisions made through the RFC process carry quite a bit of weight and have an impact on millions of developers using PHP. I believe it is reasonable to expect RFC authors to be sufficiently diligent with their RFCs to take any deadlines into account. Compared to actually writing and implementing an RFC, looking at a calendar is not the hard part.

The one place I think it would matter is when the vote closes, since that's a hard-cutoff for someone to vote or change a vote. For that, IMO the best solution is technical: Update the voting widget to both have an auto-close time, and show the start and auto-close time on the wiki page. The vote closes when the widget says it does. Presumably it would be easy for it to default to the exact same time as the start stamp, and then... I don't care about leap seconds or daylight savings time. It ends in ~2 weeks, automatically, and the exact time is right there on the page. Plan accordingly.

The voting widget already has support for an automated closing (an example is in the template). But it would certainly make sense to also show that within the widget itself. I'll see if I can send a PR to do that. I still believe that formalizing when the vote may *start* makes sense. And of course, the RFC author needs to accurately calculate the end date still. Personally I just round to the next half hour to be well over 2 weeks and to get a nice round time. I've seen others simply use the next UTC midnight after 14 days.

Best regards
Tim Düsterhus

24

Hi

Am 2025-08-29 22:21, schrieb Tim Düsterhus:

Please find the RFC at: PHP: rfc:rfc_discussion_and_vote
And the PR at: Clarify discussion and voting period rules by TimWolla · Pull Request #23 · php/policies · GitHub

I've made some more (major) changes to the PR on Friday and earlier today. Please find the changelog in the RFC itself and check the commits for details. Cooldown period resets to 2 weeks.

Best regards
Tim Düsterhus

25

On Mon, Sep 8, 2025, at 9:20 AM, Tim Düsterhus wrote:

Hi

Am 2025-09-05 18:58, schrieb Larry Garfield:

Proposed language, to turn the whole thing around:

-----

An RFC author MAY start a vote at any time, provided that:

* It has been at least two weeks since the last major change.
* It has been at least one week since the last minor change.
* There has been at least one post of any kind in the discussion thread
within the last 6 weeks.
* The author has posted an intent to open the vote at least 48 hours
prior. (This post is the only one that does not count toward the "last
6 weeks" rule.)
* There is no ongoing relevant and substantive discussion still
happening in the thread. The author may determine what qualifies as
relevant and substantive, but SHOULD be liberal in interpreting that.

-----

Thank you. That would likely require breaking up the existing structure
oh “Discussion Phase” and “Voting Phase” a little to incorporate this
cleanly. It would basically make the entire “Discussion Phase” section
obsolete, which is quite large of a change that I'll need to think about
a little more.

Perhaps the latest changes already make the language a little less
awkward?

It's an improvement, but I think it can still be improved further. It's still very verbose, and not in ways that I feel are necessary.

Would you be OK with me PR-ing a restructure to try and clarify further, including the text above?

(I used to be the documentation lead for a former employer, was a journalist for a few years, and wrote most of the bylaws for FIG. I think I'm reasonably good with words.)

(The final point is to help avoid the hecklers veto problem. If people
are just talking in circles, or there's a tangent discussion still
going that doesn't matter to this RFC, those shouldn't count.

I have just incorporated a suggestion from Ilija to soften the language
a little:
Clarify discussion and voting period rules by TimWolla · Pull Request #23 · php/policies · GitHub

I am also still not 100% convinced this level of formal-time-extension
is necessary. There are always RFCs introduced late in the cycle that
run up into freeze. That will happen no matter what we do; they may
even be going for a few months before getting there. But if consensus
is finally reached 13 days before the last day to start a vote to make
the freeze deadline, and everyone seemingly agrees with the final
change, it seems silly to say "whelp, sorry, you should have posted the
last update 12 hours earlier, now we all have to wait an extra year for
the thing we finally agreed on."

I believe a clear and objectively measurable rules are necessary to
treat everyone fairly. If 13.5 days are acceptable, are 13 days also
acceptable? What about 12.5 days? Where do we draw the line?

As I said elsewhere, if we were an organization with that level of formality and structure, I'd likely agree. But this project has actively rejected even a modicum of structure or "enforcement" ability, so it seems incongruous to have highly pedantic scheduling but loosey-goosey everything else.

The one place I think it would matter is when the vote closes, since
that's a hard-cutoff for someone to vote or change a vote. For that,
IMO the best solution is technical: Update the voting widget to both
have an auto-close time, and show the start and auto-close time on the
wiki page. The vote closes when the widget says it does. Presumably
it would be easy for it to default to the exact same time as the start
stamp, and then... I don't care about leap seconds or daylight savings
time. It ends in ~2 weeks, automatically, and the exact time is right
there on the page. Plan accordingly.

The voting widget already has support for an automated closing (an
example is in the template). But it would certainly make sense to also
show that within the widget itself. I'll see if I can send a PR to do
that. I still believe that formalizing when the vote may *start* makes
sense. And of course, the RFC author needs to accurately calculate the
end date still. Personally I just round to the next half hour to be well
over 2 weeks and to get a nice round time. I've seen others simply use
the next UTC midnight after 14 days.

Best regards
Tim Düsterhus

I would strongly recommend we make using the auto-closer mandatory, then. I don't think I've ever used it as I didn't know it was available, but I'd much rather we all use that and simplify things.

Also, I think this is new:

If issues with an accepted RFC are noticed during implementation, an errata

section explaining the necessary changes SHOULD be added.

We should include guidance on what level of changes are acceptable and which would require a new RFC, or even possibly unaccepting an RFC.

As examples:

1. Attributes went through 2-3 extra votes to fiddle with the syntax after the initial RFC.
2. Hooks had a follow-up RFC to approve a non-syntax change to error handling, in the name of performance.
3. Pipes had a non-RFC syntax change to handle the unexpected parsing issue with arrow functions.

I'd argue that #3 was a larger change than #2, yet #2 had an RFC and #3 we decided did not need one. (Not suggesting any of the above was wrong, they're just examples to show we're not currently consistent.)

I would recommend we give this decision-making to the RMs. If a change needs to be made post-vote, the RMs are empowered to decide if it needs a follow-up RFC, follow-up informal discussion, or "just do it, it's fine." (All of the above should still be included in Errata, of course.)

--Larry Garfield

26

Hi

Am 2025-09-08 17:14, schrieb Larry Garfield:

Perhaps the latest changes already make the language a little less
awkward?

It's an improvement, but I think it can still be improved further. It's still very verbose, and not in ways that I feel are necessary.

Would you be OK with me PR-ing a restructure to try and clarify further, including the text above?

Sure. Please be careful not to introduce any changes to the actual proposal, since I'm trying to keep each “functional” change in a separate commit to make it easier to follow the evolution of the policy. I might also want to add my own fixes on top, so it might also happen that I use your text as a basis only (similarly to Ilija's suggestion).

As I said elsewhere, if we were an organization with that level of formality and structure, I'd likely agree. But this project has actively rejected even a modicum of structure or "enforcement" ability, so it seems incongruous to have highly pedantic scheduling but loosey-goosey everything else.

I believe that the development of PHP has become increasingly structured, especially with the introduction of the policies repository and the associated policy RFC process. This is the 4th policy RFC (acronym naming, exception hierarchy, abstain vote, this one) I'm doing. It does not seem useful to me to make the policy less formal, just because PHP historically didn't have particularly well-written policies. The goal of the RFC is to fix that.

Also, I think this is new:

Yes, I've added that part on Friday in response to Rob (implicitly) asking for clarification whether or not RFCs may change after the vote started (specifically whether the voting deadline may change).

If issues with an accepted RFC are noticed during implementation, an errata

section explaining the necessary changes SHOULD be added.

We should include guidance on what level of changes are acceptable and which would require a new RFC, or even possibly unaccepting an RFC.

Historically that was solved by “simple agreement” (i.e. write to the list and it's okay if no one complains) if it's an obvious oversight and actual RFCs for less obvious changes or if someone asks for them. I'm not sure if this should be part of *this* RFC, since the “minor changes are okay without RFC” policy is part of the “Release Process” policy.

As examples:

1. Attributes went through 2-3 extra votes to fiddle with the syntax after the initial RFC.
2. Hooks had a follow-up RFC to approve a non-syntax change to error handling, in the name of performance.
3. Pipes had a non-RFC syntax change to handle the unexpected parsing issue with arrow functions.

I'd argue that #3 was a larger change than #2, yet #2 had an RFC and #3 we decided did not need one. (Not suggesting any of the above was wrong, they're just examples to show we're not currently consistent.)

In case of #3, the fix was just “disallowing” something entirely, leaving maximum flexibility to decide on a fix in the future. I believe the decision made for #2 was a different situation.

I would recommend we give this decision-making to the RMs. If a change needs to be made post-vote, the RMs are empowered to decide if it needs a follow-up RFC, follow-up informal discussion, or "just do it, it's fine." (All of the above should still be included in Errata, of course.)

See above, I believe this is already sufficiently clear based on the “Minor change” policy.

Best regards
Tim Düsterhus

27

On Friday 29 August 2025 22:21:41 (+02:00), Tim Düsterhus wrote:

Hi

The current policy regarding how RFC are discussed and voted on is quite dated and no longer matches the current accepted practices of the RFC process.

In the past there were several RFCs with a less-than-ideal course of discussion. Examples include RFCs being rushed through the process by less experienced contributors who are unaware that the two weeks of discussion is a *minimum* that can and often should be extended. In the weeks leading up to the feature freeze RFCs are rushed even by more experienced contributors trying to meet the deadline. This resulted in RFCs going to vote in an incomplete state, resulting in them being declined, wasting time of everyone involved when a little more discussion could've made the RFC succeed.

I've thus written up a policy RFC to clarify the current policy regarding the RFC process, to use less ambiguous language and to formalize some of the current of the currently followed undocumented practices. Examples of those would be the heads-up email of an upcoming vote and the announcement of any relevant change to the RFC text on the list, so that folks become aware of new points to be discussed without needing to check the version history all the time.

Please find the RFC at: PHP: rfc:rfc_discussion_and_vote
And the PR at: Clarify discussion and voting period rules by TimWolla · Pull Request #23 · php/policies · GitHub

As with all policy RFCs, the corresponding PR to the policies repository
will be the authoritative source of the proposal and the RFC (and
discussion) will only provide extra context. Please do not comment on
the PR (except for minor typographical or phrasing clarification
suggestions). For comments regarding the actual "policy" reply to this
discussion thread for proper visibility instead and I'll make sure to
incorporate them as appropriate.

I intend to dogfood the proposed policy during discussion and voting of this RFC. Changes to the PR will be considered changes to the RFC text.

To spell it out explicitly: This email marks the official start of the minimum discussion period of 2 weeks.

Best regards
Tim Düsterhus

If there is a likely (favourable) misunderstatement of the two weeks, my first suggestion would be to double it to four weeks. This also has the benefit that it's close to a month so the rest of the days can be used to off/on-RFC maintenance. This should better reflect the monthly rhythm of the current practice release cadence (and some day to allow -- given better planning -- half the stable release cycle to six (instead of twelve) months).

Just my two cents

-- hakre

28

Hi

Please find the RFC at: PHP: rfc:rfc_discussion_and_vote
And the PR at: Clarify discussion and voting period rules by TimWolla · Pull Request #23 · php/policies · GitHub

If you followed along the discussion, you might've seen that Larry offered to improve the phrasing of the policy for clarity. This has happened now and I think Larry did a great job at improving the structure of the policy text, while still using precise language and preserving the intended semantics. He made some changes to the policy as part of the rephrasing and I agree with them all. Specifically:

- The policy now clearly defines 1 day as 24 hours of “stopwatch time”. All the times are defined as “days” instead of “weeks” or “months”.
- There is now the grace period of 8 hours for the start of the vote, since that's the deadline that is most likely to go wrong by accident (e.g. when miscalculating after a DST change).
- There is now a maximum voting period of 28 days.
- There is now a maximum time after the intent to vote expires (7 days).
- The RFC Errata definition was expanded a little.

As before, I've added a changelog to the RFC and you can check the commits for the detailed changes. Given this is a “Major Change” to the RFC, the cooldown period resets to 14 days.

Best regards
Tim Düsterhus

29

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

If you followed along the discussion, you might've seen that Larry offered to improve the phrasing of the policy for clarity. This has happened now and I think Larry did a great job at improving the structure of the policy text, while still using precise language and preserving the intended semantics. He made some changes to the policy as part of the rephrasing and I agree with them all. Specifically:

I just realized that the RFC text was not strictly following the latest policy in the PR, the explanation of the voting widget was missing (“All voting widgets on the RFC MUST include all relevant details for that vote, as described in the "Required Majority" section below”). I have just added that (“Primary Vote requiring a 2/3 majority to accept the RFC:”) and will also make sure to include that in the RFC template, should this RFC be accepted.

I'm treating this change to the RFC text as a “Minor change”, since it's basically just clarification. It's implied by the existing policy that the single voting widget is a primary vote and that it requires a 2/3 majority.

All that said, I'm happy to hear some feedback on whether or not the updated phrasing is looking good to you? :slight_smile:

Best regards
Tim Düsterhus

30

On Wed, Sep 24, 2025, at 09:09, Tim Düsterhus wrote:

Hi

Am 2025-09-19 10:55, schrieb Tim Düsterhus:

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

If you followed along the discussion, you might’ve seen that Larry
offered to improve the phrasing of the policy for clarity. This has
happened now and I think Larry did a great job at improving the
structure of the policy text, while still using precise language and
preserving the intended semantics. He made some changes to the policy
as part of the rephrasing and I agree with them all. Specifically:

I just realized that the RFC text was not strictly following the latest
policy in the PR, the explanation of the voting widget was missing (“All
voting widgets on the RFC MUST include all relevant details for that
vote, as described in the “Required Majority” section below”). I have
just added that (“Primary Vote requiring a 2/3 majority to accept the
RFC:”) and will also make sure to include that in the RFC template,
should this RFC be accepted.

I’m treating this change to the RFC text as a “Minor change”, since it’s
basically just clarification. It’s implied by the existing policy that
the single voting widget is a primary vote and that it requires a 2/3
majority.

All that said, I’m happy to hear some feedback on whether or not the
updated phrasing is looking good to you? :slight_smile:

Best regards
Tim Düsterhus

Hi Tim,

This goes back to what I was saying: pretty much any change can be justified as “a clarification” by an author. We can choose to accept the implication of a 2/3 majority, or challenge it.

That being said, I agree with you. But it’s still worth pointing out that this can be abused and there isn’t much recourse.

I also noted you changed the text to mention that a vote can basically be restarted for any reason. This would allow an unscrupulous person to basically restart a vote if it isn’t going in the direction they want, without any reason other than an “issue” with the RFC. This means they can rely upon attrition to eventually pass an RFC that would otherwise not pass, bypassing the current “one year or with major changes” rule.

For example, the nested classes RFC was clearly not going to pass. 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. I personally wouldn’t do that, but this would explicitly allow that behavior.

— Rob

31

On 25. Sep 2025, at 05:02, Rob Landers <rob@bottled.codes> wrote:

This would allow an unscrupulous person to basically restart a vote if it isn’t going in the direction they want, without any reason other than an “issue” with the RFC. This means they can rely upon attrition to eventually pass an RFC that would otherwise not pass, bypassing the current “one year or with major changes” rule.

For example, the nested classes RFC was clearly not going to pass. 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. I personally wouldn’t do that, but this would explicitly allow that behavior.

— Rob

Hey,

I am wondering if this is actually a bad thing.
I’d argue if a RFC is evolving until it passes it does good for the language.

Maybe such "in between votes” could help to gather sentiment in complicated, lengthy discussions?
Author tries, sees that it likely will not succeed, goes back to discussion, refines, starts vote again.

There would need to be clear rules for that too, of course. Maybe maximum restarts until the 6 month rule applies?

I find this worth to think about .

Cheers
Nick

32

On Thu, Sep 25, 2025, at 3:14 AM, Nick wrote:

On 25. Sep 2025, at 05:02, Rob Landers <rob@bottled.codes> wrote:

This would allow an unscrupulous person to basically restart a vote if it isn’t going in the direction they want, without any reason other than an “issue” with the RFC. This means they can rely upon attrition to eventually pass an RFC that would otherwise not pass, bypassing the current “one year or with major changes” rule.

For example, the nested classes RFC was clearly not going to pass. 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. I personally wouldn’t do that, but this would explicitly allow that behavior.

— Rob

Hey,

I am wondering if this is actually a bad thing.
I’d argue if a RFC is evolving until it passes it does good for the language.

Maybe such "in between votes” could help to gather sentiment in
complicated, lengthy discussions?
Author tries, sees that it likely will not succeed, goes back to
discussion, refines, starts vote again.

There would need to be clear rules for that too, of course. Maybe
maximum restarts until the 6 month rule applies?

I find this worth to think about .

Cheers
Nick

I'm inclined to agree. If within 48 hours it's obvious that an RFC is doomed, I don't see an issue with the author going "eh, never mind" and saving everyone 2 weeks of waiting. If there's some key controversial bit they can change and try again, I think that's reasonable. Probably needs a Major Change cooldown period, but that's fine.

We already have a problem of discussion being a very poor quality signal for how the vote will go, Once you start getting a solid signal (vote), I don't have an issue with course correcting in that case.

--Larry Garfield

33

Hi

On 9/25/25 00:02, Rob Landers wrote:

This goes back to what I was saying: pretty much any change can be justified as “a clarification” by an author. We can choose to accept the implication of a 2/3 majority, or challenge it.

Absolutely, there is always some uncertainty when not treating something as a major change. I explicitly spelled out my reasoning when making the change, so that we as a community can discuss how we feel about this type of change and to get some discussion precedent if a similar situation arrives in the future.

If it would've been a secondary vote, I would've treated it as a major change, since in that case I would've considered that “Changing a voting widget”.

I also noted you changed the text to mention that a vote can basically be restarted for any reason. This would allow an unscrupulous person to basically restart a vote if it isn’t going in the direction they want, without any reason other than an “issue” with the RFC. This means they can rely upon attrition to eventually pass an RFC that would otherwise not pass, bypassing the current “one year or with major changes” rule.

Small correction: It's just half a year before an RFC may be reproposed.

I don't think this is a significant risk: Casting a “No” is simple and I expect the regular folks to notice if an RFC is repeatedly restarted for no good reason. If it becomes clearly abusive, I would expect this to be treated similarly to any other case of someone being abusive on the list.

For example, the nested classes RFC was clearly not going to pass. 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. I personally wouldn’t do that, but this would explicitly allow that behavior.

I agree with both Nick and Larry that I would be okay with that: 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: [Voting] Add locale for case insensitive grapheme functions - Externals

Best regards
Tim Düsterhus

34

Hi

On 9/25/25 16:46, Larry Garfield wrote:

I'm inclined to agree. If within 48 hours it's obvious that an RFC is doomed, I don't see an issue with the author going "eh, never mind" and saving everyone 2 weeks of waiting. If there's some key controversial bit they can change and try again, I think that's reasonable. Probably needs a Major Change cooldown period, but that's fine.

The current proposal already specifies that canceling a vote is a “Major change”. I also expect that any changes made *after* canceling and *before* restarting the vote would be Major changes themselves, so unless the changes happen right away and are then uncontentious, I would expect the new vote to come no earlier than 3-4 weeks after the cancelation.

Best regards
Tim Düsterhus

35

---------- Forwarded message ---------
From: youkidearitai <youkidearitai@gmail.com>
Date: 2025年9月27日(土) 11:42
Subject: Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules
To: Tim Düsterhus <tim@bastelstu.be>

2025年9月27日(土) 0:22 Tim Düsterhus <tim@bastelstu.be>:

Hi

On 9/25/25 00:02, Rob Landers wrote:
> This goes back to what I was saying: pretty much any change can be justified as “a clarification” by an author. We can choose to accept the implication of a 2/3 majority, or challenge it.

Absolutely, there is always some uncertainty when not treating something
as a major change. I explicitly spelled out my reasoning when making the
change, so that we as a community can discuss how we feel about this
type of change and to get some discussion precedent if a similar
situation arrives in the future.

If it would've been a secondary vote, I would've treated it as a major
change, since in that case I would've considered that “Changing a voting
widget”.

> I also noted you changed the text to mention that a vote can basically be restarted for any reason. This would allow an unscrupulous person to basically restart a vote if it isn’t going in the direction they want, without any reason other than an “issue” with the RFC. This means they can rely upon attrition to eventually pass an RFC that would otherwise not pass, bypassing the current “one year or with major changes” rule.

Small correction: It's just half a year before an RFC may be reproposed.

I don't think this is a significant risk: Casting a “No” is simple and I
expect the regular folks to notice if an RFC is repeatedly restarted for
no good reason. If it becomes clearly abusive, I would expect this to be
treated similarly to any other case of someone being abusive on the list.

> For example, the nested classes RFC was clearly not going to pass. 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. I personally wouldn’t do that, but this would explicitly allow that behavior.

I agree with both Nick and Larry that I would be okay with that: 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:
[Voting] Add locale for case insensitive grapheme functions - Externals

Best regards
Tim Düsterhus

Hi, Tim

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:
[Voting] Add locale for case insensitive grapheme functions - Externals

I set up an Under discussion for two weeks and sent a reminder email,
so why did it say "Derick stopped it"?
I went to vote after going through the official procedure, but for
some reason I was suddenly told NO.
My understanding is that he didn't take part in the discussion on
"Under Discussion" and didn't even vote.

Why is there such a difference in perception?

Regards
Yuya

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

Oh, No. I'm sorry, I send only to Tim.
Resend to Internals.

Regards
Yuya

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

36

2025年9月27日(土) 22:58 youkidearitai <youkidearitai@gmail.com>:

---------- Forwarded message ---------
From: youkidearitai <youkidearitai@gmail.com>
Date: 2025年9月27日(土) 11:42
Subject: Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules
To: Tim Düsterhus <tim@bastelstu.be>

2025年9月27日(土) 0:22 Tim Düsterhus <tim@bastelstu.be>:
>
> Hi
>
> On 9/25/25 00:02, Rob Landers wrote:
> > This goes back to what I was saying: pretty much any change can be justified as “a clarification” by an author. We can choose to accept the implication of a 2/3 majority, or challenge it.
>
> Absolutely, there is always some uncertainty when not treating something
> as a major change. I explicitly spelled out my reasoning when making the
> change, so that we as a community can discuss how we feel about this
> type of change and to get some discussion precedent if a similar
> situation arrives in the future.
>
> If it would've been a secondary vote, I would've treated it as a major
> change, since in that case I would've considered that “Changing a voting
> widget”.
>
> > I also noted you changed the text to mention that a vote can basically be restarted for any reason. This would allow an unscrupulous person to basically restart a vote if it isn’t going in the direction they want, without any reason other than an “issue” with the RFC. This means they can rely upon attrition to eventually pass an RFC that would otherwise not pass, bypassing the current “one year or with major changes” rule.
>
> Small correction: It's just half a year before an RFC may be reproposed.
>
> I don't think this is a significant risk: Casting a “No” is simple and I
> expect the regular folks to notice if an RFC is repeatedly restarted for
> no good reason. If it becomes clearly abusive, I would expect this to be
> treated similarly to any other case of someone being abusive on the list.
>
> > For example, the nested classes RFC was clearly not going to pass. 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. I personally wouldn’t do that, but this would explicitly allow that behavior.
>
> I agree with both Nick and Larry that I would be okay with that: 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:
> [Voting] Add locale for case insensitive grapheme functions - Externals
>
> Best regards
> Tim Düsterhus

Hi, Tim

> 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:
> [Voting] Add locale for case insensitive grapheme functions - Externals

I set up an Under discussion for two weeks and sent a reminder email,
so why did it say "Derick stopped it"?
I went to vote after going through the official procedure, but for
some reason I was suddenly told NO.
My understanding is that he didn't take part in the discussion on
"Under Discussion" and didn't even vote.

Why is there such a difference in perception?

Regards
Yuya

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

Oh, No. I'm sorry, I send only to Tim.
Resend to Internals.

Regards
Yuya

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

Hi, Internals

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.

Regards
Yuya

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

37

Hi

Am 2025-09-27 15:58, schrieb youkidearitai:

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:
[Voting] Add locale for case insensitive grapheme functions - Externals

I set up an Under discussion for two weeks and sent a reminder email,
so why did it say "Derick stopped it"?
I went to vote after going through the official procedure, but for
some reason I was suddenly told NO.

I believe there might be a misunderstanding. It definitely was not great that folks didn't speak up during the discussion and only did so after you started the vote. However I believe that you canceling the vote and making additional changes was *the right decision*. Ultimately it made the RFC better, which is a good thing.

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

My understanding is that he didn't take part in the discussion on
"Under Discussion" and didn't even vote.

Why is there such a difference in perception?

Best regards
Tim Düsterhus

38

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

39

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

40

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)

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. :folded_hands:

Cheers,
Nick