Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128617
Message-ID: <0f32efec-b6c9-4ec0-96bf-297da722aaf1@bastelstu.be>
Date: Wed, 3 Sep 2025 23:09:13 +0200
Precedence: list
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules
To: Larry Garfield <larry@garfieldtech.com>,
 php internals <internals@lists.php.net>
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>
Content-Language: en-US
In-Reply-To: <68c44ae3-8e1b-419d-9c30-906b9c2d5a81@app.fastmail.com>
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

On 9/3/25 22:07, Larry Garfield wrote:
> "If the proposal
> is a repeated discussion of an existing RFC, with or without modification, it
> MUST still be announced on the list for discussion."
> 
> What does "repeated discussion" mean?  Is that "I've taken over this old RFC and revised it", or "no one has commented on this RFC in the last month so now it has to be a new thread" or "I'm saying things that have already been said because I didn't read the list yet"?

That is a good point. I've taken over that sentence from the original 
policy without giving it much thought. I think that sentence can simply 
be dropped entirely. The last paragraph in the “Proposal Initiation” 
section and all the following sections should sufficiently define the 
proper process.

> 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.

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.

> " Minor changes to the RFC text include adding new examples, updating
> existing examples, adding additional explanation or clarification, or any other
> changes that are not purely editorial."
> 
> We must be working with different definitions of "editorial", because those seem editorial to me.

I just searched for "editorial changes definition", found these 
resources, which seem to agree with my definition:

https://transportation.org/materials/wp-content/uploads/sites/36/2023/01/Editorial-vs-Technical-Revisions-in-Standards.pdf

https://portal.etsi.org/Services/editHelp/Search/FAQs/Difference-editorial-technical-comments

https://www.transparency.gov.au/publications/attorney-general-s/office-of-parliamentary-counsel/office-of-parliamentary-counsel-annual-report-2022-23/chapter-3%3A-additional-information/editorial-changes

Nevertheless it is quite possible that I selected the wrong term there. 
Do you have a suggestion for a more appropriate word?

> "Similarly RFC authors
> SHOULD NOT proceed with an announced vote if new discussion points are brought
> forward after the voting announcement."
> 
> Any discussion point, or valid discussion points?  For some definition of valid?  This seems like an easily exploitable way to "hecklers veto" an RFC by never letting it go to a vote by just talking too much.  As a concrete example, and not to pick on her but it's the first to come to mind, Juliette had a long response to the Property Hooks thread that came in a day before voting was to start, after multiple months of discussion.  It didn't really add anything *new* to the discussion; it didn't point out any bugs in the design, just general unease with its extensiveness.  Should that comment force a delay in the vote by its simple existence?  I firmly think not.
> 
> I would recommend at least adding "if new relevant discussion points are brought forward".  Where "relevant" is at the RFC author's good faith judgement.  However, some discussions just go around and around at length but go nowhere.  The author should be able to put a pin in it and say "'nuf said, we're voting, that will resolve this question, vote no if you are on team X."  Otherwise, again, we just keep talking forever.

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 can easily see a mostly-run-its-course discussion thread that would be ready for a vote in early December, but that would then run into the holiday blackout period, so the authors delay the vote until mid-January.  (I'm pretty sure I've done that before.)  However, that could run into the 6-week fallow rule proposal.  Should there be any sort of allowance for that, so that the mandatory blackout period doesn't force delaying an RFC even more?

The policy specifies that the vote must not *end* within that period 
(though I realize that I should probably update it to "must neither 
start or end" - otherwise it would allow for *creative* placement of the 
discussion period).

The suggestion is to simply extend the voting period appropriately such 
that the vote starts say December 10 and ends January 10th for a total 
of 31 days.

Alternatively just sending an email "This RFC is still alive, I'm just 
waiting until after the holidays" would reset the 6-week period. The 
goal really is to make sure that the discussion thread is sitting 
somewhere near the top of the inbox and the policy therefore indicates 
“any email”.

Best regards
Tim Düsterhus