Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128653
Precedence: list
MIME-Version: 1.0
Date: Mon, 08 Sep 2025 16:20:36 +0200
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules
In-Reply-To: <e1a75f2c-f7c0-45ff-a9a9-12088df2e978@app.fastmail.com>
References: <53cdbf5b-7c6e-4ba1-9987-332634cab527@bastelstu.be>
 <4624748F-0C62-4E3C-81D0-5CDC56FEC55F@nicksdot.dev>
 <c177c3340f458a4de58fefb4107c1753@bastelstu.be>
 <dd1e34df1b5b740948ab24f0b4bd367b@bastelstu.be>
 <68c44ae3-8e1b-419d-9c30-906b9c2d5a81@app.fastmail.com>
 <0f32efec-b6c9-4ec0-96bf-297da722aaf1@bastelstu.be>
 <e1a75f2c-f7c0-45ff-a9a9-12088df2e978@app.fastmail.com>
Message-ID: <4b809fc105b2cb53992dedde44cf6bc8@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

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