Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:128619 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id 9C69B1A00BC for ; Wed, 3 Sep 2025 22:08:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1756937236; bh=4QSqfnykMiZNHQgp0DpsqKarjeReJCNapZEtUXo1woI=; h=Date:From:To:In-Reply-To:References:Subject:From; b=h1eWWiCjZ231oepMVz5kNT1ydLN8YtlGdjLGxIwe95LG8vASVcPvQ5oqt6tK56u+3 FOhRNKDwVZXAXk7i+f9VtzI2UM7U3TjchxNDH7ZQhKWgOXqE4+JKFyB3N384R4Mhxe W6LKyqNj7v1hKISzh56BrRMqFnTvxceaSBr3F6LheJrUSpwhYDxrwAb5Zw2SwOZ0zy R4HYC8om/ZZ5Kwj4D9JQA+U03KTpz7HYFuCAyhycLYojq6EDYZljQsnWFqBviuxiJj pUt2SPLLgPrmiFjtjE1bp0JFHjSp0I2vrRS8xmd1VVMA449ojx3RrUr15tQMjthNcj 7n4T3XAay5KNw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B44A11801DF for ; Wed, 3 Sep 2025 22:07:15 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_40,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from fout-a5-smtp.messagingengine.com (fout-a5-smtp.messagingengine.com [103.168.172.148]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 3 Sep 2025 22:07:15 +0000 (UTC) Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfout.phl.internal (Postfix) with ESMTP id 5ADF6EC04A4; Wed, 3 Sep 2025 18:08:44 -0400 (EDT) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-05.internal (MEProxy); Wed, 03 Sep 2025 18:08:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1756937324; x=1757023724; bh=aW5frDpMtf R55e3L3AaH054xKluEazc4qwfgLzqk+AY=; b=A9wT7gS5Tkjx8/92RACrPkvrEH OfNoWILtbLFfxnmk5HjFu9AWENtmGf3uWJZ6BqtciaBYxutHErRLt+YKoXPiqjYE j7VIfX8QYG6p6qV2NspsylzEnMH7TkU/V9GBguovDVXdG65m0ISUVcUzCBsR99A2 eZkgB/9zXn2XvuO20OWlbSJW0bStYsVBC2CVzVnRwIfbp0d/aeSRtlL1SwcRsM94 +xLgqie6oXYN2LU6Itows4Z8JrtmYI/bjzfwwCTtgoIMplndV1b4SsgaQxki8fEG icwWvcn0zD0Vj4nONPPynRrDv4MCnZnlF87B+zWxecY/ucSlAuKnz6FKK/Cg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1756937324; x=1757023724; bh=aW5frDpMtfR55e3L3AaH054xKluEazc4qwf gLzqk+AY=; b=oX8O9tiqozWN0GLiBjlISLS1ZLZFoTqIhtJoHnU9Wotn77A26bE nISTRWe8gYwkRI7jHuetrnM/x1njhPopJ9s91di6+E3lIQl7OTgEH8vg7aWFUIjc C7f+odYjHdrnWw5WbUB+LHZTawp3yIqU+0v66GMlgcyH67QRvZoHhNBxSGzfFmHL BbG+Ec1W+bqJUlHGjFPzJ+EVf8mhb4TOQeZS9Hid0vsRnCete/PUYPrWHHgZUPx6 DDJrlSG99u7WSAtx/Y7iVO2taJO7f9G7GeZmgOP6C/rs10VNegD2NDPxA/O/NhN0 vkZdadyrN94/PyUjcTD0yGQvN1eqFs+2XJA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdegfedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh epofggfffhvffkjghfufgtsegrtderreertdejnecuhfhrohhmpedftfhosgcunfgrnhgu vghrshdfuceorhhosgessghothhtlhgvugdrtghouggvsheqnecuggftrfgrthhtvghrnh epheegfefhhfeffeefieejgedtjeefvdefveehgfffgedvheejtefgvddvheejffegnecu ffhomhgrihhnpehtrhgrnhhsphhorhhtrghtihhonhdrohhrghdpvghtshhirdhorhhgpd htrhgrnhhsphgrrhgvnhgthidrghhovhdrrghunecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomheprhhosgessghothhtlhgvugdrtghouggvshdpnh gspghrtghpthhtohepfedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepthhimhes sggrshhtvghlshhtuhdrsggvpdhrtghpthhtoheplhgrrhhrhiesghgrrhhfihgvlhguth gvtghhrdgtohhmpdhrtghpthhtohepihhnthgvrhhnrghlsheslhhishhtshdrphhhphdr nhgvth X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id D4371182007E; Wed, 3 Sep 2025 18:08:43 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: list list-help: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 X-ThreadId: AyNXb5nLmdzs Date: Thu, 04 Sep 2025 00:07:48 +0200 To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= , "Larry Garfield" , "php internals" Message-ID: In-Reply-To: <0f32efec-b6c9-4ec0-96bf-297da722aaf1@bastelstu.be> References: <53cdbf5b-7c6e-4ba1-9987-332634cab527@bastelstu.be> <4624748F-0C62-4E3C-81D0-5CDC56FEC55F@nicksdot.dev> <68c44ae3-8e1b-419d-9c30-906b9c2d5a81@app.fastmail.com> <0f32efec-b6c9-4ec0-96bf-297da722aaf1@bastelstu.be> Subject: Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules Content-Type: multipart/alternative; boundary=7f4508b1bcfb41588d8deed00a42087f From: rob@bottled.codes ("Rob Landers") --7f4508b1bcfb41588d8deed00a42087f Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, Sep 3, 2025, at 23:09, Tim D=C3=BCsterhus wrote: > Hi >=20 > On 9/3/25 22:07, Larry Garfield wrote: > > "If the proposal > > is a repeated discussion of an existing RFC, with or without modific= ation, it > > MUST still be announced on the list for discussion." > >=20 > > 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 la= st month so now it has to be a new thread" or "I'm saying things that ha= ve already been said because I didn't read the list yet"? >=20 > That is a good point. I've taken over that sentence from the original=20 > policy without giving it much thought. I think that sentence can simpl= y=20 > be dropped entirely. The last paragraph in the =E2=80=9CProposal Initi= ation=E2=80=9D=20 > section and all the following sections should sufficiently define the=20 > proper process. >=20 > > The language for the "extending the discussion period" paragraph is = highly clumsy and confusing. The existence of the last sentence to clar= ify it is evidence of that. I would recommend rewriting it. (I can off= er suggestions if you're open to it.) >=20 > I am open to suggestions, yes. Not being a native speaker makes it eas= y=20 > to write stuff that makes sense to me, but are confusing to folks that=20 > actually understand the language :-) >=20 > > Really, though... what is actually being proposed, and is not actua= lly a widespread convention right now, is a policy of "the vote may star= t 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. >=20 > That would be an accurate summary of what that part of the policy is=20 > trying to codify, yes. >=20 > And I would say that this matches the lived reality: For most=20 > (successful) RFCs the author makes some changes, announces them on the=20 > list and then ask for feedback (e.g. from the person who originally=20 > suggested the changes or who pointed out the mistake), which can easil= y=20 > take a day or two to arrive. This then often sparks additional=20 > discussion that takes a few more days to settle down due to varying=20 > schedules and timezones. At this point a week easily passed. >=20 > I would also say that it matches the spirit of a =E2=80=9Cminimum disc= ussion=20 > period=E2=80=9D. It does not appear very useful that it is technically= allowed=20 > by policy to replace the entire RFC text 10 minutes before the vote.=20 > Something something RFC of Theseus. >=20 > In cases where the actual proposal (rather than e.g. the examples)=20 > repeatedly changes over the course of the discussion generally indicat= es=20 > some severe problem or oversight with the RFC. It would often be more=20 > appropriate for the RFC author to go back to the drawing board,=20 > consulting with some close advisors to figure out how to fix these=20 > problems rather than discussing all those details on the list. >=20 > > " Minor changes to the RFC text include adding new examples, updating > > existing examples, adding additional explanation or clarification, o= r any other > > changes that are not purely editorial." > >=20 > > We must be working with different definitions of "editorial", becaus= e those seem editorial to me. >=20 > I just searched for "editorial changes definition", found these=20 > resources, which seem to agree with my definition: >=20 > https://transportation.org/materials/wp-content/uploads/sites/36/2023/= 01/Editorial-vs-Technical-Revisions-in-Standards.pdf >=20 > https://portal.etsi.org/Services/editHelp/Search/FAQs/Difference-edito= rial-technical-comments >=20 > 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 >=20 > Nevertheless it is quite possible that I selected the wrong term there= .=20 > Do you have a suggestion for a more appropriate word? >=20 > > "Similarly RFC authors > > SHOULD NOT proceed with an announced vote if new discussion points a= re brought > > forward after the voting announcement." > >=20 > > Any discussion point, or valid discussion points? For some definiti= on of valid? This seems like an easily exploitable way to "hecklers vet= o" 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 t= o mind, Juliette had a long response to the Property Hooks thread that c= ame in a day before voting was to start, after multiple months of discus= sion. 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 extensive= ness. Should that comment force a delay in the vote by its simple exist= ence? I firmly think not. > >=20 > > I would recommend at least adding "if new relevant discussion points= are brought forward". Where "relevant" is at the RFC author's good fai= th judgement. However, some discussions just go around and around at le= ngth but go nowhere. The author should be able to put a pin in it and s= ay "'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. >=20 > That section is intentionally using the =E2=80=9CSHOULD NOT=E2=80=9D i= ndicator, to avoid=20 > folks being able to filibuster an RFC. It also intentionally used the=20 > word =E2=80=9Cnew=E2=80=9D in front of =E2=80=9Cdiscussion points=E2=80= =9D to indicate that repeating=20 > something from before (something that most likely already was rejected=20 > by the RFC author) does not constitute a new discussion point. The=20 > intention is to encourage RFC authors to give suggestions sufficient=20 > deliberation (and ideally a response), even if it comes in after the=20 > voting announcement. >=20 > I'm happy to rephrase if you have any suggestions. >=20 > > I can easily see a mostly-run-its-course discussion thread that woul= d be ready for a vote in early December, but that would then run into th= e holiday blackout period, so the authors delay the vote until mid-Janua= ry. (I'm pretty sure I've done that before.) However, that could run i= nto the 6-week fallow rule proposal. Should there be any sort of allowa= nce for that, so that the mandatory blackout period doesn't force delayi= ng an RFC even more? >=20 > The policy specifies that the vote must not *end* within that period=20 > (though I realize that I should probably update it to "must neither=20 > start or end" - otherwise it would allow for *creative* placement of t= he=20 > discussion period). >=20 > The suggestion is to simply extend the voting period appropriately suc= h=20 > that the vote starts say December 10 and ends January 10th for a total=20 > of 31 days. >=20 > Alternatively just sending an email "This RFC is still alive, I'm just=20 > waiting until after the holidays" would reset the 6-week period. The=20 > goal really is to make sure that the discussion thread is sitting=20 > somewhere near the top of the inbox and the policy therefore indicates=20 > =E2=80=9Cany email=E2=80=9D. >=20 > Best regards > Tim D=C3=BCsterhus >=20 Hi Tim, I=E2=80=99m still trying to understand the problem this language is solv= ing, can you help me out here? It is incredibly precise and detailed, bu= t gets into over-specification, IMHO. Traditionally, PHP policy has lean= ed 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=E2=80=99t seem equi= pped to deal with "your vote ended 1 hour too early" type situations. =E2=80=94 Rob --7f4508b1bcfb41588d8deed00a42087f Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Wed, Sep 3, 2025, at 23:09, Tim D=C3=BCsterhus wrot= e:
Hi

On 9/3/25 22:07, Larry Garfield wrote:
> "I= f the proposal
> is a repeated discussion of an existing RF= C, with or without modification, it
> MUST still be announc= ed on the list for discussion."
> 
> What= does "repeated discussion" mean?  Is that "I've taken over this ol= d 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 ori= ginal 
policy without giving it much thought. I think tha= t sentence can simply 
be dropped entirely. The last para= graph in the =E2=80=9CProposal Initiation=E2=80=9D 
secti= on and all the following sections should sufficiently define the 
proper process.

> The language for = the "extending the discussion period" paragraph is highly clumsy and con= fusing.  The existence of the last sentence to clarify it is eviden= ce of that.  I would recommend rewriting it.  (I can offer sug= gestions if you're open to it.)

I am open to su= ggestions, yes. Not being a native speaker makes it easy 
to write stuff that makes sense to me, but are confusing to folks that&= nbsp;
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 v= ote may start two weeks after the last substantive change."  For so= me definition of "substantive."  If that is the intent, it should j= ust say that.  And we should discuss directly if we actually want t= hat requirement.

That would be an accurate summ= ary of what that part of the policy is 
trying to codify,= yes.

And I would say that this matches the liv= ed reality: For most 
(successful) RFCs the author makes = some changes, announces them on the 
list and then ask fo= r feedback (e.g. from the person who originally 
suggeste= d the changes or who pointed out the mistake), which can easily 
take a day or two to arrive. This then often sparks additional&n= bsp;
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 matche= s the spirit of a =E2=80=9Cminimum discussion 
period=E2=80= =9D. It does not appear very useful that it is technically allowed =
by policy to replace the entire RFC text 10 minutes before th= e vote. 
Something something RFC of Theseus.
In cases where the actual proposal (rather than e.g. the ex= amples) 
repeatedly changes over the course of the discus= sion generally indicates 
some severe problem or oversigh= t with the RFC. It would often be more 
appropriate for t= he RFC author to go back to the drawing board, 
consultin= g 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 ne= w examples, updating
> existing examples, adding additional= explanation or clarification, or any other
> changes that = are not purely editorial."
> 
> We must b= e 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:




=
Nevertheless it is quite possible that I selected the wrong t= erm there. 
Do you have a suggestion for a more appropria= te 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 ea= sily 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 t= o pick on her but it's the first to come to mind, Juliette had a long re= sponse to the Property Hooks thread that came in a day before voting was= to start, after multiple months of discussion.  It didn't really a= dd anything *new* to the discussion; it didn't point out any bugs in the= design, just general unease with its extensiveness.  Should that c= omment force a delay in the vote by its simple existence?  I firmly= think not.
> 
> I would recommend at lea= st adding "if new relevant discussion points are brought forward". = Where "relevant" is at the RFC author's good faith judgement.  How= ever, some discussions just go around and around at length but go nowher= e.  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 t= eam X."  Otherwise, again, we just keep talking forever.
=
That section is intentionally using the =E2=80=9CSHOULD N= OT=E2=80=9D indicator, to avoid 
folks being able to fili= buster an RFC. It also intentionally used the 
word =E2=80= =9Cnew=E2=80=9D in front of =E2=80=9Cdiscussion points=E2=80=9D to indic= ate that repeating 
something from before (something that= most likely already was rejected 
by the RFC author) doe= s not constitute a new discussion point. The 
intention i= s to encourage RFC authors to give suggestions sufficient 
deliberation (and ideally a response), even if it comes in after the&n= bsp;
voting announcement.

I'm happy t= o rephrase if you have any suggestions.

> I = can easily see a mostly-run-its-course discussion thread that would be r= eady for a vote in early December, but that would then run into the holi= day blackout period, so the authors delay the vote until mid-January.&nb= sp; (I'm pretty sure I've done that before.)  However, that could r= un into the 6-week fallow rule proposal.  Should there be any sort = of allowance for that, so that the mandatory blackout period doesn't for= ce delaying an RFC even more?

The policy specif= ies that the vote must not *end* within that period 
(tho= ugh I realize that I should probably update it to "must neither 
start or end" - otherwise it would allow for *creative* placemen= t of the 
discussion period).

Th= e suggestion is to simply extend the voting period appropriately such&nb= sp;
that the vote starts say December 10 and ends January 10th= for a total 
of 31 days.

Altern= atively 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 th= read is sitting 
somewhere near the top of the inbox and = the policy therefore indicates 
=E2=80=9Cany email=E2=80=9D= .

Best regards
Tim D=C3=BCsterhus

Hi Tim,

I=E2= =80=99m still trying to understand the problem this language is solving,= can you help me out here? It is incredibly precise and detailed, but ge= ts into over-specification, IMHO. Traditionally, PHP policy has leaned t= owards 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 correctl= y, this is generally enforced by the CoC and it doesn=E2=80=99t seem equ= ipped to deal with "your vote ended 1 hour too early" type situations.

=E2=80=94 Rob
--7f4508b1bcfb41588d8deed00a42087f--