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