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
