On Wed, Sep 3, 2025, at 4:09 PM, Tim Düsterhus wrote: >> The language for the "extending the discussion period" paragraph is highly >> clumsy and confusing. The existence of the last sentence to clarify it is >> evidence of that. I would recommend rewriting it. (I can offer suggestions >> if you're open to it.) > > I am open to suggestions, yes. Not being a native speaker makes it easy > to write stuff that makes sense to me, but are confusing to folks that > actually understand the language :-) > >> 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
