On Mon, Sep 8, 2025, at 9:20 AM, Tim Düsterhus wrote: > Hi > > Am 2025-09-05 18:58, schrieb Larry Garfield: >> Proposed language, to turn the whole thing around: >> >> ----- >> >> An RFC author MAY start a vote at any time, provided that: >> >> * It has been at least two weeks since the last major change. >> * It has been at least one week since the last minor change. >> * There has been at least one post of any kind in the discussion thread >> within the last 6 weeks. >> * The author has posted an intent to open the vote at least 48 hours >> prior. (This post is the only one that does not count toward the "last >> 6 weeks" rule.) >> * There is no ongoing relevant and substantive discussion still >> happening in the thread. The author may determine what qualifies as >> relevant and substantive, but SHOULD be liberal in interpreting that. >> >> ----- > > Thank you. That would likely require breaking up the existing structure > oh “Discussion Phase” and “Voting Phase” a little to incorporate this > cleanly. It would basically make the entire “Discussion Phase” section > obsolete, which is quite large of a change that I'll need to think about > a little more. > > Perhaps the latest changes already make the language a little less > awkward?
It's an improvement, but I think it can still be improved further. It's still very verbose, and not in ways that I feel are necessary. Would you be OK with me PR-ing a restructure to try and clarify further, including the text above? (I used to be the documentation lead for a former employer, was a journalist for a few years, and wrote most of the bylaws for FIG. I think I'm reasonably good with words.) >> (The final point is to help avoid the hecklers veto problem. If people >> are just talking in circles, or there's a tangent discussion still >> going that doesn't matter to this RFC, those shouldn't count. > > I have just incorporated a suggestion from Ilija to soften the language > a little: > 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? As I said elsewhere, if we were an organization with that level of formality and structure, I'd likely agree. But this project has actively rejected even a modicum of structure or "enforcement" ability, so it seems incongruous to have highly pedantic scheduling but loosey-goosey everything else. >> The one place I think it would matter is when the vote closes, since >> that's a hard-cutoff for someone to vote or change a vote. For that, >> IMO the best solution is technical: Update the voting widget to both >> have an auto-close time, and show the start and auto-close time on the >> wiki page. The vote closes when the widget says it does. Presumably >> it would be easy for it to default to the exact same time as the start >> stamp, and then... I don't care about leap seconds or daylight savings >> time. It ends in ~2 weeks, automatically, and the exact time is right >> there on the page. Plan accordingly. > > The voting widget already has support for an automated closing (an > example is in the template). But it would certainly make sense to also > show that within the widget itself. I'll see if I can send a PR to do > that. I still believe that formalizing when the vote may *start* makes > sense. And of course, the RFC author needs to accurately calculate the > end date still. Personally I just round to the next half hour to be well > over 2 weeks and to get a nice round time. I've seen others simply use > the next UTC midnight after 14 days. > > Best regards > Tim Düsterhus I would strongly recommend we make using the auto-closer mandatory, then. I don't think I've ever used it as I didn't know it was available, but I'd much rather we all use that and simplify things. Also, I think this is new: > If issues with an accepted RFC are noticed during implementation, an errata section explaining the necessary changes SHOULD be added. We should include guidance on what level of changes are acceptable and which would require a new RFC, or even possibly unaccepting an RFC. As examples: 1. Attributes went through 2-3 extra votes to fiddle with the syntax after the initial RFC. 2. Hooks had a follow-up RFC to approve a non-syntax change to error handling, in the name of performance. 3. Pipes had a non-RFC syntax change to handle the unexpected parsing issue with arrow functions. I'd argue that #3 was a larger change than #2, yet #2 had an RFC and #3 we decided did not need one. (Not suggesting any of the above was wrong, they're just examples to show we're not currently consistent.) I would recommend we give this decision-making to the RMs. If a change needs to be made post-vote, the RMs are empowered to decide if it needs a follow-up RFC, follow-up informal discussion, or "just do it, it's fine." (All of the above should still be included in Errata, of course.) --Larry Garfield
