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: https://wiki.php.net/rfc/rfc_discussion_and_vote
And the PR at: https://github.com/php/policies/pull/23
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
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
This looks sensible to me, but I probably would like to see the history
of these time extensions in the RFC wiki page itself too. Some of them
already include version numbers with changes made in these[1], and that
would be an excellent point as to where to add this.
[1] https://wiki.php.net/rfc/domdocument_html5_parser#changelog
cheers,
Derick
Hi
Am 2025-09-01 11:41, schrieb Derick Rethans:
This looks sensible to me, but I probably would like to see the history
of these time extensions in the RFC wiki page itself too. Some of them
What specifically do you want to see? Just a changelog with “minor” /
“major” indicators?
I've intentionally used the email on the list as a source of truth,
since that is when others become aware of the changes, allowing them to
review. For complex RFCs it's often the case that changes to the RFC
happen incrementally over multiple days, obvious things are adjusted
right away and less trivial stuff is double-checked against the
implementation and possibly discussed with a co-author. Only after
having made all the changes and having proof-read them, they would then
be announced on the list in bulk, ready for the next round of discussion
and resetting the timer.
Best regards
Tim Düsterhus
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: https://wiki.php.net/rfc/rfc_discussion_and_vote
And the PR at: https://github.com/php/policies/pull/23As 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
Hey Tim,
As requested in the other thread, I am reposting it here. I’d appreciate if you could add it to your RFC!
And while I we are on it, I will add another point because your RFC touches this anyway.
- Reference of discussion in RFCs
When I try to look into the discussions of older RFCs to find out why they ended up the way they did, it’s not easy. You hardly can find them. This is because they are often not referenced in the RFC itself.
Going forward, would it make sense to make it mandatory to reference '[Discussion]' and '[Vote]' in the RFC text itself?
- Make revisions public
I don’t quite understand why RFC revisions are not public. I believe it would be very helpful to see the diffs of the RFCs. Because then everyone can see how and why a RFC evolved. Revisions could be listed at the bottom; on click you see the diff. Perhaps it makes sense to only apply this change to RFCs that would be proposed after this change potentially will be accepted.
—
For completeness, I copied the two answers from the other thread below and CC Allen:
Hey there!
When I try to look into the discussions of older RFCs to find out why they ended up the way they did, it’s not easy. You hardly can find them. This is because they are often not referenced in the RFC itself.
Going forward, would it make sense to make it mandatory to reference '[Discussion]' and '[Vote]' in the RFC text itself?
Cheers
Nick
FYI I can usually find most RFC discussions by searching on https://externals.io https://externals.io/ for the RFC titleTo be clear, I would also still encourage RFC authors to add discussion and vote thread links to RFCs. I think it helps people who are not familiar with the RFC process when RFCs are linked outside of the list, such as on Reddit or social media. I'll often add a comment to RFC posts on r/php to link the discussion threads so people can follow the list discussion.
Also, some discussions are harder to find when there's many other list discussions that mention the same keywords as the RFC title.
Thought: This could potentially be automated with a script that looks for list emails with a RFC link in the body. If the email body contains a RFC link, the subject contains the RFC title and either [Discussion] or [Vote], then add a reference to the linked RFC wiki page.
Thanks, I knew of externals.
It can be helpful sometimes but not always. The search is quite limited, as you also noted.
I think we agree that it cannot be wrong to have it in the RFC.
Hi
Am 2025-09-01 12:28, schrieb Nick:
When I try to look into the discussions of older RFCs to find out why they ended up the way they did, it’s not easy. You hardly can find them. This is because they are often not referenced in the RFC itself.
Going forward, would it make sense to make it mandatory to reference '[Discussion]' and '[Vote]' in the RFC text itself?I was having troubles finding the corresponding discussion thread for some RFCs myself before (and regretfully did not always add the links to the list archives myself to my own RFCs). I think this makes sense and I'm happy to include this requirement as part of my current “Clarify discussion and voting period rules” RFC. Would you mind sending another email to the discussion thread of that one to have it all in a single location: https://news-web.php.net/php.internals/128594?
Best regards
Tim Düsterhus
Done. :)
—
Cheers,
Nick
Hey all, hey Tim
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: https://wiki.php.net/rfc/rfc_discussion_and_vote
And the PR at: https://github.com/php/policies/pull/23As 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
I already commented on the PR^1 but want to reiterate this comment.
Right now the new wording of the RFC speaks of certain week-periods with
a certain amount of hours in parentheses. Like "2 weeks (336 hours)".
While I understand the idea my nitpick to this was to not assume
86,400-second days. As the examples in the RFC explain quite
understandable that the voting ends (earliest) at 16:00H when it started
at 16:00 hours I would not put that into actual hours.
If we see that the number of hours elapsed is a reason to question the
validity of a vote - and as far as I understand it that is what this is
in essence trying to prevent - then in my opinion we have a different
problem that is not going to be resolved based on the number of elapsed
hours.
In addition, adding 2 weeks to a datetime will add (usually) 14 days to
the date but the time will stay the same anyhow.
Hence I'd recommend removing the hours and just keep the weeks.
My 0.02€
Cheers
Andreas
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+---------------------------------------------------------------------+
Hi
Am 2025-09-01 15:50, schrieb Andreas Heigl:
While I understand the idea my nitpick to this was to not assume
86,400-second days. As the examples in the RFC explain quite
understandable that the voting ends (earliest) at 16:00H when it
started at 16:00 hours I would not put that into actual hours.
[…]
In addition, adding 2 weeks to a datetime will add (usually) 14 days to
the date but the time will stay the same anyhow.
That depends on the timezone. DST changes do not all happen at the same
time or day around the world, sometimes they do not happen at all.
Having a purely day-and-time-based definition is needlessly ambiguous, 2
days could be validly interpreted as everything between just over 24
hours (when the beginning of the period is at 23:59:59 of day 1 and the
end at 00:00:00 of day 3) and 49 hours (“same time across a DST
change”).
If we see that the number of hours elapsed is a reason to question the
validity of a vote - and as far as I understand it that is what this is
in essence trying to prevent - then in my opinion we have a different
problem that is not going to be resolved based on the number of elapsed
hours.
Policy, like contracts, exist to make an agreement in preparation for
future situations where folks disagree. While I certainly hope that we
won't need to be pedantic about the policy and that everyone is acting
in good faith, I want to avoid needing to discuss what “2 weeks” means
in a situation that is already stressful for everyone involved due to
other circumstances. Having a clear definition in the policy makes it
easier to cut that discussion short.
However you are right that it's easy to accidentally violate the “hour
rule” in case of DST changes. What about slightly decreasing them to
give some wiggle room to account for varying schedules and DST /
timezone changes?
- 2 days: 40 hours (1 full day + 16 hours)
- 1 week: 160 hours (7 full days + 16 hours)
- 2 weeks: 328 hours (13 full days + 16 hours)
Best regards
Tim Düsterhus
Am 02.09.25 um 12:41 schrieb Tim Düsterhus:
Hi
Am 2025-09-01 15:50, schrieb Andreas Heigl:
While I understand the idea my nitpick to this was to not assume
86,400-second days. As the examples in the RFC explain quite
understandable that the voting ends (earliest) at 16:00H when it
started at 16:00 hours I would not put that into actual hours.
[…]
In addition, adding 2 weeks to a datetime will add (usually) 14 days
to the date but the time will stay the same anyhow.That depends on the timezone. DST changes do not all happen at the same
time or day around the world, sometimes they do not happen at all.
Having a purely day-and-time-based definition is needlessly ambiguous, 2
days could be validly interpreted as everything between just over 24
hours (when the beginning of the period is at 23:59:59 of day 1 and the
end at 00:00:00 of day 3) and 49 hours (“same time across a DST change”).If we see that the number of hours elapsed is a reason to question the
validity of a vote - and as far as I understand it that is what this
is in essence trying to prevent - then in my opinion we have a
different problem that is not going to be resolved based on the number
of elapsed hours.Policy, like contracts, exist to make an agreement in preparation for
future situations where folks disagree. While I certainly hope that we
won't need to be pedantic about the policy and that everyone is acting
in good faith, I want to avoid needing to discuss what “2 weeks” means
in a situation that is already stressful for everyone involved due to
other circumstances. Having a clear definition in the policy makes it
easier to cut that discussion short.However you are right that it's easy to accidentally violate the “hour
rule” in case of DST changes. What about slightly decreasing them to
give some wiggle room to account for varying schedules and DST /
timezone changes?
- 2 days: 40 hours (1 full day + 16 hours)
- 1 week: 160 hours (7 full days + 16 hours)
- 2 weeks: 328 hours (13 full days + 16 hours)
When reading about the detailled hours in the PR, I was a little bit
disturbed about the exact calculation of hours. It looked overly
pedandic (read: very legally inspired) to me.
I just checked very few of the latest voting anouncements. Most times
some kind of relation to UTC was provided.
I'd say, there's no real issue about an additional/missing hour (or two)
due to DST changes.
Assuming the end time is clearly defined and someone miscaluclated it
because of DST changes that should not be an issue in a reasonable time
frame. (Discussing about a voting result because of such a minor
miscalculation found later wouldn't be nice either.)
For extending the voting periods I'd stay with days as other values have
similar issue and make calculations (slightly) harder.
Would it be an alternative to add some general sentence about using UTC
time and that calculations should use UTC, but if there are some minor
miscalculations (e.g. due to missed DST changes) that is acceptable?
Best regards,
Thomas
Hi
Am 2025-09-02 13:43, schrieb Thomas Nunninger:
very legally inspired
Well, yes. That was the goal. RFCs in general should describe the
proposal in way that does not leave any ambiguity about what exactly is
being proposed, so that everyone is able to make an informed decision.
And that extends to the policy documents. The policy documents
effectively are contracts that govern how the PHP project wants to
develop the language and how it wants to make decisions.
I'd say, there's no real issue about an additional/missing hour (or
two) due to DST changes.
Yes, that makes sense to me.
For extending the voting periods I'd stay with days as other values
have similar issue and make calculations (slightly) harder.
My suggested decreased “hour values” with the 8 hour leeway would just
work when keeping the “day value” in mind: If I just take the same
hour+minute X days in the future, then I'm definitely over the required
hours.
Would it be an alternative to add some general sentence about using UTC
time and that calculations should use UTC, but if there are some minor
miscalculations (e.g. due to missed DST changes) that is acceptable?
I believe that defining what a day is, is more complex than specifying
an hour value - even when only considering UTC. To use my previous
example: Is 2025-09-02 23:50 UTC until 2025-09-04 02:00 UTC two days?
The difference between 4 and 2 is 2. Also what is a “minor
miscalculation”? Is it 1 hour? 2 hours? See how we're back to an
hour-based definition?
I'm in Europe/Berlin, which makes calculating in UTC reasonably easy for
me to do, since my waking hours are generally all within the same UTC
day. This is different for folks outside of Europe, since they regularly
cross UTC days within their waking hours, making it more likely for
(significant) errors to sneak in.
Best regards
Tim Düsterhus
Hi
Am 2025-09-02 13:43, schrieb Thomas Nunninger:
very legally inspired
Well, yes. That was the goal. RFCs in general should describe the proposal in way that does not leave any ambiguity about what exactly is being proposed, so that everyone is able to make an informed decision. And that extends to the policy documents. The policy documents effectively are contracts that govern how the PHP project wants to develop the language and how it wants to make decisions.
I'd say, there's no real issue about an additional/missing hour (or two) due to DST changes.
Yes, that makes sense to me.
For extending the voting periods I'd stay with days as other values have similar issue and make calculations (slightly) harder.
My suggested decreased “hour values” with the 8 hour leeway would just work when keeping the “day value” in mind: If I just take the same hour+minute X days in the future, then I'm definitely over the required hours.
Would it be an alternative to add some general sentence about using UTC time and that calculations should use UTC, but if there are some minor miscalculations (e.g. due to missed DST changes) that is acceptable?
I believe that defining what a day is, is more complex than specifying an hour value - even when only considering UTC. To use my previous example: Is 2025-09-02 23:50 UTC until 2025-09-04 02:00 UTC two days? The difference between 4 and 2 is 2. Also what is a “minor miscalculation”? Is it 1 hour? 2 hours? See how we're back to an hour-based definition?
I'm in Europe/Berlin, which makes calculating in UTC reasonably easy for me to do, since my waking hours are generally all within the same UTC day. This is different for folks outside of Europe, since they regularly cross UTC days within their waking hours, making it more likely for (significant) errors to sneak in.
Best regards
Tim Düsterhus
I just want to throw in that this sounds fairly easy to automate.
There is already a checkbox "Minor Changes” when editing the RFC.
This means, the timestamp from the last major change can be used to simply display a “voting allowed earliest at” time.
For the voting, there could be another checkbox for “open voting”. Which could validate the period, before actually allowing it.
Cheers
Nick
Hi
Am 2025-09-01 14:46, schrieb Nick:
- Reference of discussion in RFCs
When I try to look into the discussions of older RFCs to find out why
they ended up the way they did, it’s not easy. You hardly can find
them. This is because they are often not referenced in the RFC itself.Going forward, would it make sense to make it mandatory to reference
'[Discussion]' and '[Vote]' in the RFC text itself?
I'll make the requested adjustments and then follow up here on the list.
- Make revisions public
I don’t quite understand why RFC revisions are not public. I believe it
would be very helpful to see the diffs of the RFCs. Because then
everyone can see how and why a RFC evolved. Revisions could be listed
at the bottom; on click you see the diff. Perhaps it makes sense to
only apply this change to RFCs that would be proposed after this change
potentially will be accepted.
They were previously public and were restricted to logged-in users with
https://github.com/php/web-wiki/commit/0e5a3029f95610ddb230a8bd3901875b9c4b82ee.
My understanding is that this was done to fend off various scrapers, but
I was not involved in that decision. I agree that having the diff
publicly available would be useful.
Best regards
Tim Düsterhus
Hi
Am 2025-09-02 15:08, schrieb Tim Düsterhus:
- Reference of discussion in RFCs
When I try to look into the discussions of older RFCs to find out why
they ended up the way they did, it’s not easy. You hardly can find
them. This is because they are often not referenced in the RFC itself.Going forward, would it make sense to make it mandatory to reference
'[Discussion]' and '[Vote]' in the RFC text itself?I'll make the requested adjustments and then follow up here on the
list.
I have made the change in the following commit:
https://github.com/php/policies/pull/23/commits/fdd28a322aa03ccc822d8f0ac3fa1d934a519a7e,
added the link to the discussion of this very RFC to the RFC itself and
updated the changelog section. As this is a major change to the RFC, the
discussion period will go for another 2 weeks from now.
Given that the emails do not immediately become available in the
archives, I've used the “as soon as possible wording” with deadline for
the voting announcement and voting close respectively. While the RFC is
in progress, the threads should still be easy to find. The goal is to
preserve easy access after several months have passed, so I don't think
a super tight deadline is necessary as long as it happens eventually.
Best regards
Tim Düsterhus
Hi
Am 2025-09-02 15:08, schrieb Tim Düsterhus:
- Reference of discussion in RFCs
When I try to look into the discussions of older RFCs to find out why
they ended up the way they did, it’s not easy. You hardly can find
them. This is because they are often not referenced in the RFC itself.Going forward, would it make sense to make it mandatory to reference
'[Discussion]' and '[Vote]' in the RFC text itself?I'll make the requested adjustments and then follow up here on the
list.I have made the change in the following commit:
https://github.com/php/policies/pull/23/commits/fdd28a322aa03ccc822d8f0ac3fa1d934a519a7e,
added the link to the discussion of this very RFC to the RFC itself and
updated the changelog section. As this is a major change to the RFC,
the
discussion period will go for another 2 weeks from now.Given that the emails do not immediately become available in the
archives, I've used the “as soon as possible wording” with deadline for
the voting announcement and voting close respectively. While the RFC is
in progress, the threads should still be easy to find. The goal is to
preserve easy access after several months have passed, so I don't think
a super tight deadline is necessary as long as it happens eventually.
"If the proposal
is a repeated discussion of an existing RFC, with or without modification, it
MUST still be announced on the list for discussion."
What does "repeated discussion" mean? Is that "I've taken over this old RFC and revised it", or "no one has commented on this RFC in the last month so now it has to be a new thread" or "I'm saying things that have already been said because I didn't read the list yet"?
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.)
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.
" Minor changes to the RFC text include adding new examples, updating
existing examples, adding additional explanation or clarification, or any other
changes that are not purely editorial."
We must be working with different definitions of "editorial", because those seem editorial to me.
"Similarly RFC authors
SHOULD NOT proceed with an announced vote if new discussion points are brought
forward after the voting announcement."
Any discussion point, or valid discussion points? For some definition of valid? This seems like an easily exploitable way to "hecklers veto" an RFC by never letting it go to a vote by just talking too much. As a concrete example, and not to pick on her but it's the first to come to mind, Juliette had a long response to the Property Hooks thread that came in a day before voting was to start, after multiple months of discussion. It didn't really add anything new to the discussion; it didn't point out any bugs in the design, just general unease with its extensiveness. Should that comment force a delay in the vote by its simple existence? I firmly think not.
I would recommend at least adding "if new relevant discussion points are brought forward". Where "relevant" is at the RFC author's good faith judgement. However, some discussions just go around and around at length but go nowhere. The author should be able to put a pin in it and say "'nuf said, we're voting, that will resolve this question, vote no if you are on team X." Otherwise, again, we just keep talking forever.
I can easily see a mostly-run-its-course discussion thread that would be ready for a vote in early December, but that would then run into the holiday blackout period, so the authors delay the vote until mid-January. (I'm pretty sure I've done that before.) However, that could run into the 6-week fallow rule proposal. Should there be any sort of allowance for that, so that the mandatory blackout period doesn't force delaying an RFC even more?
--Larry Garfield
Hi
"If the proposal
is a repeated discussion of an existing RFC, with or without modification, it
MUST still be announced on the list for discussion."What does "repeated discussion" mean? Is that "I've taken over this old RFC and revised it", or "no one has commented on this RFC in the last month so now it has to be a new thread" or "I'm saying things that have already been said because I didn't read the list yet"?
That is a good point. I've taken over that sentence from the original
policy without giving it much thought. I think that sentence can simply
be dropped entirely. The last paragraph in the “Proposal Initiation”
section and all the following sections should sufficiently define the
proper process.
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 :-)
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.
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.
" Minor changes to the RFC text include adding new examples, updating
existing examples, adding additional explanation or clarification, or any other
changes that are not purely editorial."We must be working with different definitions of "editorial", because those seem editorial to me.
I just searched for "editorial changes definition", found these
resources, which seem to agree with my definition:
https://portal.etsi.org/Services/editHelp/Search/FAQs/Difference-editorial-technical-comments
Nevertheless it is quite possible that I selected the wrong term there.
Do you have a suggestion for a more appropriate word?
"Similarly RFC authors
SHOULD NOT proceed with an announced vote if new discussion points are brought
forward after the voting announcement."Any discussion point, or valid discussion points? For some definition of valid? This seems like an easily exploitable way to "hecklers veto" an RFC by never letting it go to a vote by just talking too much. As a concrete example, and not to pick on her but it's the first to come to mind, Juliette had a long response to the Property Hooks thread that came in a day before voting was to start, after multiple months of discussion. It didn't really add anything new to the discussion; it didn't point out any bugs in the design, just general unease with its extensiveness. Should that comment force a delay in the vote by its simple existence? I firmly think not.
I would recommend at least adding "if new relevant discussion points are brought forward". Where "relevant" is at the RFC author's good faith judgement. However, some discussions just go around and around at length but go nowhere. The author should be able to put a pin in it and say "'nuf said, we're voting, that will resolve this question, vote no if you are on team X." Otherwise, again, we just keep talking forever.
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 can easily see a mostly-run-its-course discussion thread that would be ready for a vote in early December, but that would then run into the holiday blackout period, so the authors delay the vote until mid-January. (I'm pretty sure I've done that before.) However, that could run into the 6-week fallow rule proposal. Should there be any sort of allowance for that, so that the mandatory blackout period doesn't force delaying an RFC even more?
The policy specifies that the vote must not end within that period
(though I realize that I should probably update it to "must neither
start or end" - otherwise it would allow for creative placement of the
discussion period).
The suggestion is to simply extend the voting period appropriately such
that the vote starts say December 10 and ends January 10th for a total
of 31 days.
Alternatively just sending an email "This RFC is still alive, I'm just
waiting until after the holidays" would reset the 6-week period. The
goal really is to make sure that the discussion thread is sitting
somewhere near the top of the inbox and the policy therefore indicates
“any email”.
Best regards
Tim Düsterhus
Hi
"If the proposal
is a repeated discussion of an existing RFC, with or without modification, it
MUST still be announced on the list for discussion."What does "repeated discussion" mean? Is that "I've taken over this old RFC and revised it", or "no one has commented on this RFC in the last month so now it has to be a new thread" or "I'm saying things that have already been said because I didn't read the list yet"?
That is a good point. I've taken over that sentence from the original
policy without giving it much thought. I think that sentence can simply
be dropped entirely. The last paragraph in the “Proposal Initiation”
section and all the following sections should sufficiently define the
proper process.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 :-)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.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." Minor changes to the RFC text include adding new examples, updating
existing examples, adding additional explanation or clarification, or any other
changes that are not purely editorial."We must be working with different definitions of "editorial", because those seem editorial to me.
I just searched for "editorial changes definition", found these
resources, which seem to agree with my definition:https://portal.etsi.org/Services/editHelp/Search/FAQs/Difference-editorial-technical-comments
Nevertheless it is quite possible that I selected the wrong term there.
Do you have a suggestion for a more appropriate word?"Similarly RFC authors
SHOULD NOT proceed with an announced vote if new discussion points are brought
forward after the voting announcement."Any discussion point, or valid discussion points? For some definition of valid? This seems like an easily exploitable way to "hecklers veto" an RFC by never letting it go to a vote by just talking too much. As a concrete example, and not to pick on her but it's the first to come to mind, Juliette had a long response to the Property Hooks thread that came in a day before voting was to start, after multiple months of discussion. It didn't really add anything new to the discussion; it didn't point out any bugs in the design, just general unease with its extensiveness. Should that comment force a delay in the vote by its simple existence? I firmly think not.
I would recommend at least adding "if new relevant discussion points are brought forward". Where "relevant" is at the RFC author's good faith judgement. However, some discussions just go around and around at length but go nowhere. The author should be able to put a pin in it and say "'nuf said, we're voting, that will resolve this question, vote no if you are on team X." Otherwise, again, we just keep talking forever.
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 can easily see a mostly-run-its-course discussion thread that would be ready for a vote in early December, but that would then run into the holiday blackout period, so the authors delay the vote until mid-January. (I'm pretty sure I've done that before.) However, that could run into the 6-week fallow rule proposal. Should there be any sort of allowance for that, so that the mandatory blackout period doesn't force delaying an RFC even more?
The policy specifies that the vote must not end within that period
(though I realize that I should probably update it to "must neither
start or end" - otherwise it would allow for creative placement of the
discussion period).The suggestion is to simply extend the voting period appropriately such
that the vote starts say December 10 and ends January 10th for a total
of 31 days.Alternatively just sending an email "This RFC is still alive, I'm just
waiting until after the holidays" would reset the 6-week period. The
goal really is to make sure that the discussion thread is sitting
somewhere near the top of the inbox and the policy therefore indicates
“any email”.Best regards
Tim Düsterhus
Hi Tim,
I’m still trying to understand the problem this language is solving, can you help me out here? It is incredibly precise and detailed, but gets into over-specification, IMHO. Traditionally, PHP policy has leaned towards principle and illustrative examples over exact prescriptions. Is this intended to shift away from that approach?
Further, how will this be enforced? Currently, if I understand correctly, this is generally enforced by the CoC and it doesn’t seem equipped to deal with "your vote ended 1 hour too early" type situations.
— Rob
Hi
Am 2025-09-04 00:07, schrieb Rob Landers:
I’m still trying to understand the problem this language is solving,
can you help me out here? It is incredibly precise and detailed, but
gets into over-specification, IMHO. Traditionally, PHP policy has
leaned towards principle and illustrative examples over exact
prescriptions. Is this intended to shift away from that approach?
The language is trying to solve ambiguity. The current phrasing of the
policy is full of words like “maybe”, “might”, “should”, which leave
room for interpretation. As I have mentioned in my reply to Thomas, a
(formal) policy is intended to to allow cut discussion short in cases of
disagreement by allowing someone to point towards the policy and say:
“The policy we agreed on clearly specifies that X, but this rule was
violated. I object with proceeding until this violation is resolved.”.
It should not possible for the other side to “well actually it could
also mean Y”, because they disagree. As an example the current policy
states:
There'd be a minimum of 2 weeks between when an RFC that touches the
language is brought up on this list and when it's voted on is required.
Other RFCs might use a smaller timeframe, but it should be at least a
week.
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.
Further, how will this be enforced? Currently, if I understand
correctly, this is generally enforced by the CoC and it doesn’t seem
equipped to deal with "your vote ended 1 hour too early" type
situations.
This is a good point that indeed should be written down in some way. I
generally expect everyone to act in good faith, i.e. to only violate the
policy by accident and to immediately remediate any issues once made
aware of the mistake. Violations of the cooldown period should generally
be recognized when pre-announcing the vote and the RFC author should
then acknowledge the violation in a reply, wait a little more and then
pre-announce the vote at a later point. Violations of the
pre-announcement period should be recognized when starting the vote and
the RFC author should then acknowledge the violation, cancel the vote
and restart it after a new pre-announcement (with a new title to clear
out any votes). The Wiki tracks the time of voting, so any votes cast
after the voting period has ended would be ignored (which would only
really matter in cases of close votes).
If the RFC author follows through with a vote, despite being in
violation of the rules and being made aware of it, the result of the
vote would be void. I'd say that if no one points out the violation
after a “reasonable period of time” has passed, the violation is
considered to not have occurred (i.e. it should not be possible to void
a vote at day 13 of the voting period).
Best regards
Tim Düsterhus
Hi
Am 2025-09-04 00:07, schrieb Rob Landers:
I’m still trying to understand the problem this language is solving,
can you help me out here? It is incredibly precise and detailed, but
gets into over-specification, IMHO. Traditionally, PHP policy has
leaned towards principle and illustrative examples over exact
prescriptions. Is this intended to shift away from that approach?The language is trying to solve ambiguity. The current phrasing of the
policy is full of words like “maybe”, “might”, “should”, which leave
room for interpretation. As I have mentioned in my reply to Thomas, a
(formal) policy is intended to to allow cut discussion short in cases of
disagreement by allowing someone to point towards the policy and say:
“The policy we agreed on clearly specifies that X, but this rule was
violated. I object with proceeding until this violation is resolved.”.
It should not possible for the other side to “well actually it could
also mean Y”, because they disagree. As an example the current policy
states:There'd be a minimum of 2 weeks between when an RFC that touches the
language is brought up on this list and when it's voted on is required.
Other RFCs might use a smaller timeframe, but it should be at least a
week.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?
Somehow I doubt this would actually fly, despite "maybe, technically", being within the rules.
Further, how will this be enforced? Currently, if I understand
correctly, this is generally enforced by the CoC and it doesn’t seem
equipped to deal with "your vote ended 1 hour too early" type
situations.This is a good point that indeed should be written down in some way. I
generally expect everyone to act in good faith, i.e. to only violate the
policy by accident and to immediately remediate any issues once made
aware of the mistake. Violations of the cooldown period should generally
be recognized when pre-announcing the vote and the RFC author should
then acknowledge the violation in a reply, wait a little more and then
pre-announce the vote at a later point. Violations of the
pre-announcement period should be recognized when starting the vote and
the RFC author should then acknowledge the violation, cancel the vote
and restart it after a new pre-announcement (with a new title to clear
out any votes). The Wiki tracks the time of voting, so any votes cast
after the voting period has ended would be ignored (which would only
really matter in cases of close votes).
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:
- 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?
- 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.
- 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).
- 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.
- It says that you can't add or change a voting widget, but you can remove them freely without triggering a vote reset.
- 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.
- 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?
- 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"?
If the RFC author follows through with a vote, despite being in
violation of the rules and being made aware of it, the result of the
vote would be void. I'd say that if no one points out the violation
after a “reasonable period of time” has passed, the violation is
considered to not have occurred (i.e. it should not be possible to void
a vote at day 13 of the voting period).Best regards
Tim Düsterhus
The new rules could allow some creative people to bypass the cooldown period altogether:
- 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.
- 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.
My point, hopefully, is that the more specific you are, the more wiggle room people actually have both to attack and defend. At the end of the day, this is a people problem, not a policy problem. It's one thing to clarify, but another to specify.
— Rob
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.
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:
- 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.
- 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.
- 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.
- 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 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.
- 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.
- 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.
- 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:
- 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.
- 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
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.
😭
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#128272I 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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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:
- 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.
- 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
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 :-)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
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:
https://github.com/php/policies/pull/23/commits/2d022476e647ab12ac781673597fec2ad87cba82
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
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:
https://github.com/php/policies/pull/23/commits/2d022476e647ab12ac781673597fec2ad87cba82I 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:
- Attributes went through 2-3 extra votes to fiddle with the syntax after the initial RFC.
- Hooks had a follow-up RFC to approve a non-syntax change to error handling, in the name of performance.
- 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
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:
- Attributes went through 2-3 extra votes to fiddle with the syntax
after the initial RFC.- Hooks had a follow-up RFC to approve a non-syntax change to error
handling, in the name of performance.- 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
Hi Tim
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
Thank you for your initiative to solidify the unwritten rules we've
been following for a while. A few comments:
When making non-editorial / non-typographical changes to the normative section of the RFC text (i.e. to the actual proposal, excluding future scope, rejected features and references) the discussion period MUST be extended.
It should also be acceptable to add examples whose semantics are
already clearly specified textually.
The discussion period MUST be extended by 2 weeks (336 hours) in case of major changes. It MUST be extended by 1 week (168 hours) in case of minor changes.
Do you think there's a risk that known issues will be covered up to
dodge the extended discussion period, most notably to avoid missing
feature freeze? Of course, this risk already exists, but with less
wiggle room it may increase further.
Similarly RFC authors SHOULD NOT proceed with an announced vote if new discussion points are brought forward after the voting announcement.
Larry has already touched on this. The policy should define "new
discussion points". It would be frustrating if some obscure but new
suggestion can make RFCs miss the deadline. Maybe this can be worded
in a way that encourages the author to incorporate late feedback and
to NOT start the vote if it would objectively improve the proposal. I
realize the policy says SHOULD NOT, but a newer contributor might very
well interpret this as frowned upon.
As others have noted, I also think some tolerance for the hourly
requirement is reasonable.
I think you should also define what the consequences of failing to
adhere to the policy are. Does it invalidate the vote? Who can call
for the consequences to be implemented? Can the vote be restarted when
the minimum discussion period ends? Etc.
Side-note: It might be useful to call this time the cooldown period.
I.e. major changes (including the first announcement of the RFC)
require a 2 week cooldown period, minor changes require a 1 week
cooldown period. During this period, no new (reasonable) discussions
or changes to the specification should happen.
Ilija
Hi
Am 2025-09-04 00:14, schrieb Ilija Tovilo:
When making non-editorial / non-typographical changes to the normative
section of the RFC text (i.e. to the actual proposal, excluding future
scope, rejected features and references) the discussion period MUST be
extended.It should also be acceptable to add examples whose semantics are
already clearly specified textually.
Adding examples is currently considered a “minor change” (i.e. 1 week).
I consider that useful, so that participants are able to double-check
all examples for correctness. It's not uncommon for examples to not
actually work or to be out-of-sync with the “formal proposal”. Given
that examples are also intended to help folks understand the RFC better,
they might also make people realize that they misunderstood something
that was already there, which might lead to additional useful
discussion.
I therefore believe that examples should not be treated as a “purely
editorial” change.
The discussion period MUST be extended by 2 weeks (336 hours) in case
of major changes. It MUST be extended by 1 week (168 hours) in case of
minor changes.Do you think there's a risk that known issues will be covered up to
dodge the extended discussion period, most notably to avoid missing
feature freeze? Of course, this risk already exists, but with less
wiggle room it may increase further.
Sure, that is a risk. But I believe that folks are sufficiently diligent
to call that out in the voting thread and to vote accordingly.
Intentionally doing a worse version of an RFC to meet a deadline does
not seem to be a wise choice on the RFC author's end.
Similarly RFC authors SHOULD NOT proceed with an announced vote if new
discussion points are brought forward after the voting announcement.Larry has already touched on this. The policy should define "new
discussion points". It would be frustrating if some obscure but new
suggestion can make RFCs miss the deadline. Maybe this can be worded
in a way that encourages the author to incorporate late feedback and
to NOT start the vote if it would objectively improve the proposal. I
realize the policy says SHOULD NOT, but a newer contributor might very
well interpret this as frowned upon.
I'm happy to accept suggestions for a good phrasing.
I think you should also define what the consequences of failing to
adhere to the policy are. Does it invalidate the vote? Who can call
for the consequences to be implemented? Can the vote be restarted when
the minimum discussion period ends? Etc.
I have put some thoughts into my reply to Rob:
https://news-web.php.net/php.internals/128634. I'm happy to hear what
others think and will then incorporate that in the proposal.
Side-note: It might be useful to call this time the cooldown period.
I.e. major changes (including the first announcement of the RFC)
require a 2 week cooldown period, minor changes require a 1 week
cooldown period. During this period, no new (reasonable) discussions
or changes to the specification should happen.
I've already made the rename yesterday.
Best regards
Tim Düsterhus
Hi
Am 2025-08-29 22:21, 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
I've just made another (major) update to the PR:
- Dropped the “Repeated Discussion” sentence, as announced in my reply
to Larry. - Disallowed starting a vote during EOY, as suggested in my reply to
Larry. - Renamed “Minimum Discussion Period” to “Cooldown Period”, as suggested
by Ilija. This change allowed to simplify the phrasing quite a bit. - Various phrasing clean-up.
Please check the (atomic) commits for the detailed changes.
This email resets the cooldown period of this RFC to 2 weeks.
Best regards
Tim Düsterhus
Hi
Am 2025-08-29 22:21, 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
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
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: https://wiki.php.net/rfc/rfc_discussion_and_vote
And the PR at: https://github.com/php/policies/pull/23As 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
Hi
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:
- 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
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/23If 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? :-)
Best regards
Tim Düsterhus
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/23If 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? :-)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
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
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
Hi
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
Hi
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:
https://externals.io/message/127791#127803
Best regards
Tim Düsterhus
Hi Tim
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/23All 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:
https://externals.io/message/128594#128724. If the vote is passing and
a bigger issue is discovered, allowing the authors to retract the vote
seems like the better approach than relying on voters to change their
vote, especially if there's not enough time for a follow-up RFC. If
the vote is failing, keeping it going only wastes time when a solution
could already be discussed. The linked message says:
Had this policy existed, taking what feedback I had already gotten, I 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
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:
https://externals.io/message/128594#128724. If the vote is passing and
a bigger issue is discovered, allowing the authors to retract the vote
seems like the better approach than relying on voters to change their
vote, especially if there's not enough time for a follow-up RFC. If
the vote is failing, keeping it going only wastes time when a solution
could already be discussed. The linked message says:Had this policy existed, taking what feedback I had already gotten, I
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
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:
https://github.com/php/policies/pull/23/commits/3311f2e72402b456aff78de4e4d8f8b8ccbcd05c
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
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:
https://externals.io/message/128594#128724. If the vote is passing and
a bigger issue is discovered, allowing the authors to retract the vote
seems like the better approach than relying on voters to change their
vote, especially if there's not enough time for a follow-up RFC. If
the vote is failing, keeping it going only wastes time when a solution
could already be discussed. The linked message says:Had this policy existed, taking what feedback I had already gotten, I
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
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
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