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
