On Wed, Sep 3, 2025, at 23:09, Tim Düsterhus wrote:
> 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
>
Hi Tim,
I’m still trying to understand the problem this language is solving, can you help me out here? It
is incredibly precise and detailed, but gets into over-specification, IMHO. Traditionally, PHP
policy has leaned towards principle and illustrative examples over exact prescriptions. Is this
intended to shift away from that approach?
Further, how will this be enforced? Currently, if I understand correctly, this is generally enforced
by the CoC and it doesn’t seem equipped to deal with "your vote ended 1 hour too early"
type situations.
— Rob