Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128638
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Thu, 04 Sep 2025 20:17:30 +0200
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: "Larry Garfield" <larry@garfieldtech.com>,
 "php internals" <internals@lists.php.net>
Message-ID: <73866cf1-6ac9-4e30-9273-0634cea43352@app.fastmail.com>
In-Reply-To: <7ab7580d355569eed3d69aec92dacd4c@bastelstu.be>
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>
 <a8a5b6c7-e84e-426c-9c0c-2905861319c6@app.fastmail.com>
 <7ab7580d355569eed3d69aec92dacd4c@bastelstu.be>
Subject: Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules
Content-Type: multipart/alternative;
 boundary=47af7c0f1b3b430eab6484b7810ab03c
From: rob@bottled.codes ("Rob Landers")

--47af7c0f1b3b430eab6484b7810ab03c
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 4, 2025, at 15:48, Tim D=C3=BCsterhus wrote:
> Hi
>=20
> Am 2025-09-04 00:07, schrieb Rob Landers:
> > I=E2=80=99m still trying to understand the problem this language is =
solving,=20
> > can you help me out here? It is incredibly precise and detailed, but=20
> > gets into over-specification, IMHO. Traditionally, PHP policy has=20
> > leaned towards principle and illustrative examples over exact=20
> > prescriptions. Is this intended to shift away from that approach?
>=20
> The language is trying to solve ambiguity. The current phrasing of the=20
> policy is full of words like =E2=80=9Cmaybe=E2=80=9D, =E2=80=9Cmight=E2=
=80=9D, =E2=80=9Cshould=E2=80=9D, which leave=20
> room for interpretation. As I have mentioned in my reply to Thomas, a=20
> (formal) policy is intended to to allow cut discussion short in cases =
of=20
> disagreement by allowing someone to point towards the policy and say:=20
> =E2=80=9CThe policy we agreed on *clearly* specifies that X, but this =
rule was=20
> violated. I object with proceeding until this violation is resolved.=E2=
=80=9D.=20
> It should not possible for the other side to =E2=80=9Cwell actually it=
 could=20
> also mean Y=E2=80=9D, because they disagree. As an example the current=
 policy=20
> states:
>=20
> > There'd be a minimum of 2 weeks between when an RFC that touches the=20
> > language is brought up on this list and when it's voted on is requir=
ed.=20
> > Other RFCs might use a smaller timeframe, but it should be at least =
a=20
> > week.
>=20
> Specifically =E2=80=9COther RFCs=E2=80=9D (i.e. RFCs that do not touch=
 the language,=20
> which is not actually defined) =E2=80=9Cmight=E2=80=9D (this probably =
should read =E2=80=9Cmay=E2=80=9D)=20
> use a =E2=80=9Csmaller timeframe=E2=80=9D that =E2=80=9Cshould be at l=
east a week=E2=80=9D (i.e. it may=20
> also be 2 hours). In other words, that policy is completely useless to=20
> resolve any cases of disagreement, since it allows basically anything.

So, someone could create an RFC, saying "Jo ElePHant, III" is "President=
 of PHP", set the voting period for exactly one minute, vote on it thems=
elves, and close the vote, and whomever "Jo ElePHant, III" is, would hav=
e to be the President of PHP before the announcement email is even deliv=
ered to the entire list?

Somehow I doubt this would actually fly, despite "maybe, technically", b=
eing within the rules.

> > Further, how will this be enforced? Currently, if I understand=20
> > correctly, this is generally enforced by the CoC and it doesn=E2=80=99=
t seem=20
> > equipped to deal with "your vote ended 1 hour too early" type=20
> > situations.
>=20
> This is a good point that indeed should be written down in some way. I=20
> generally expect everyone to act in good faith, i.e. to only violate t=
he=20
> policy by accident and to immediately remediate any issues once made=20
> aware of the mistake. Violations of the cooldown period should general=
ly=20
> be recognized when pre-announcing the vote and the RFC author should=20
> then acknowledge the violation in a reply, wait a little more and then=20
> pre-announce the vote at a later point. Violations of the=20
> pre-announcement period should be recognized when starting the vote an=
d=20
> the RFC author should then acknowledge the violation, cancel the vote=20
> and restart it after a new pre-announcement (with a new title to clear=20
> out any votes). The Wiki tracks the time of voting, so any votes cast=20
> after the voting period has ended would be ignored (which would only=20
> really matter in cases of close votes).

I think the more you make a policy pedantic, the easier it is to play pe=
dantic games. I had a couple of hours to sit on the train and think thro=
ugh some loopholes in the current proposed text:

 1. The 336 hours is oddly specifc. It also begs the question: "what abo=
ut leap seconds?" Could someone cause an entire revote simply by pointin=
g out that the vote closed one second earlier than 336 hours because one=
 of those hours had one less second? Does it matter? Perhaps saying "~33=
6 hours" to drive the intent home without saying "exactly" that amount o=
f time?
 2. Just about any change could be construed as an "obvious typo" or "ed=
itorializing" A stronger definition could be "any change that clarifies =
but does not alter the meaning (e.g. "frrm" -> "from" but not "form" -> =
"from"), while changes that affect APIs, semantics, or options are never=
 typos". Even then, someone could just create a stub and simply argue th=
at all their edits are clarifying the stub... so this one will be tricky.
 3. Forbidding starting/ending on Dec 17->Jan 10 will probably backfire.=
 It would behoove someone to schedule a voting start on Dec 16, so that =
it would end on Jan 11. Albeit, that is longer than 2 weeks, but it's sh=
orter than waiting until Jan 11 to start a vote... arguably, this is pro=
bably worse than what the rule intends to solve. If the concern is holid=
ay churn (heh, uninitentional rhyming), it might be better to forbid *st=
arting* during that period, but let existing votes play out as normal (a=
nd maybe picking a sooner date).
 4. The official start and threading is ambiguous. For example, I can ad=
d a coauthor on my RFC. Then "announce" the RFC by both authors but only=
 have discussions in the later thread. I could move to a vote after two =
weeks, no matter what is happening in another "unofficial" thread.
 5. It says that you can't add or change a voting widget, but you can re=
move them freely without triggering a vote reset.
 6. It might be a good idea to add "all durations are measured in UTC ca=
lendar time, ignoring leap seconds". One could argue that announcing the=
 vote at 11:59:59 Monday and starting the vote at 00:00:01 Wednesday wou=
ld satisfy the 2 day/48 hour rule by arguing time zone shenanigans.
 7. If a vote ends at 15:09, does it actually ends at 15:09:00, or will =
votes be accepted until 15:09:59.99?
 8. vote extension hack: can someone change a vote end-date after the vo=
te has already started? Thus if the results are unfavorible, can I simpl=
y just extend the voting period until I get the results I want, literall=
y increasing it by 24 hours every day until it passes by simply stating =
"I am still on holiday"?

>=20
> If the RFC author follows through with a vote, despite being in=20
> violation of the rules and being made aware of it, the result of the=20
> vote would be void. I'd say that if no one points out the violation=20
> after a =E2=80=9Creasonable period of time=E2=80=9D has passed, the vi=
olation is=20
> considered to not have occurred (i.e. it should not be possible to voi=
d=20
> a vote at day 13 of the voting period).
>=20
> Best regards
> Tim D=C3=BCsterhus
>=20

The new rules could allow some creative people to bypass the cooldown pe=
riod altogether:
 1. Someone could create an empty RFC, and announce it. Then "clarify" a=
nd "editorialize" the RFC (easier to do with a coauthor to back you up) =
minutes before the two weeks elapse, then call a vote, with most people =
having long dismissed the empty RFC as junk.
 2. You could simply create a v2 of an RFC minutes/days after the failed=
 vote and go straight to a vote; claiming the cooldown started from the =
original RFC.
My point, hopefully, is that the more specific you are, the more wiggle =
room people actually have both to attack and defend. At the end of the d=
ay, this is a people problem, not a policy problem. It's one thing to cl=
arify, but another to specify.

=E2=80=94 Rob
--47af7c0f1b3b430eab6484b7810ab03c
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Thu, Sep =
4, 2025, at 15:48, Tim D=C3=BCsterhus wrote:</div><blockquote type=3D"ci=
te" id=3D"qt" style=3D""><div>Hi</div><div><br></div><div>Am 2025-09-04 =
00:07, schrieb Rob Landers:</div><div>&gt; I=E2=80=99m still trying to u=
nderstand the problem this language is solving,&nbsp;</div><div>&gt; can=
 you help me out here? It is incredibly precise and detailed, but&nbsp;<=
/div><div>&gt; gets into over-specification, IMHO. Traditionally, PHP po=
licy has&nbsp;</div><div>&gt; leaned towards principle and illustrative =
examples over exact&nbsp;</div><div>&gt; prescriptions. Is this intended=
 to shift away from that approach?</div><div><br></div><div>The language=
 is trying to solve ambiguity. The current phrasing of the&nbsp;</div><d=
iv>policy is full of words like =E2=80=9Cmaybe=E2=80=9D, =E2=80=9Cmight=E2=
=80=9D, =E2=80=9Cshould=E2=80=9D, which leave&nbsp;</div><div>room for i=
nterpretation. As I have mentioned in my reply to Thomas, a&nbsp;</div><=
div>(formal) policy is intended to to allow cut discussion short in case=
s of&nbsp;</div><div>disagreement by allowing someone to point towards t=
he policy and say:&nbsp;</div><div>=E2=80=9CThe policy we agreed on *cle=
arly* specifies that X, but this rule was&nbsp;</div><div>violated. I ob=
ject with proceeding until this violation is resolved.=E2=80=9D.&nbsp;</=
div><div>It should not possible for the other side to =E2=80=9Cwell actu=
ally it could&nbsp;</div><div>also mean Y=E2=80=9D, because they disagre=
e. As an example the current policy&nbsp;</div><div>states:</div><div><b=
r></div><div>&gt; There'd be a minimum of 2 weeks between when an RFC th=
at touches the&nbsp;</div><div>&gt; language is brought up on this list =
and when it's voted on is required.&nbsp;</div><div>&gt; Other RFCs migh=
t use a smaller timeframe, but it should be at least a&nbsp;</div><div>&=
gt; week.</div><div><br></div><div>Specifically =E2=80=9COther RFCs=E2=80=
=9D (i.e. RFCs that do not touch the language,&nbsp;</div><div>which is =
not actually defined) =E2=80=9Cmight=E2=80=9D (this probably should read=
 =E2=80=9Cmay=E2=80=9D)&nbsp;</div><div>use a =E2=80=9Csmaller timeframe=
=E2=80=9D that =E2=80=9Cshould be at least a week=E2=80=9D (i.e. it may&=
nbsp;</div><div>also be 2 hours). In other words, that policy is complet=
ely useless to&nbsp;</div><div>resolve any cases of disagreement, since =
it allows basically anything.</div></blockquote><div><br></div><div>So, =
someone could create an RFC, saying "Jo ElePHant, III" is "President of =
PHP", set the voting period for exactly one minute, vote on it themselve=
s, and close the vote, and whomever "Jo ElePHant, III" is, would have to=
 be the President of PHP before the announcement email is even delivered=
 to the entire list?</div><div><br></div><div>Somehow I doubt this would=
 actually fly, despite "maybe, technically", being within the rules.</di=
v><div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>&gt=
; Further, how will this be enforced? Currently, if I understand&nbsp;</=
div><div>&gt; correctly, this is generally enforced by the CoC and it do=
esn=E2=80=99t seem&nbsp;</div><div>&gt; equipped to deal with "your vote=
 ended 1 hour too early" type&nbsp;</div><div>&gt; situations.</div><div=
><br></div><div>This is a good point that indeed should be written down =
in some way. I&nbsp;</div><div>generally expect everyone to act in good =
faith, i.e. to only violate the&nbsp;</div><div>policy by accident and t=
o immediately remediate any issues once made&nbsp;</div><div>aware of th=
e mistake. Violations of the cooldown period should generally&nbsp;</div=
><div>be recognized when pre-announcing the vote and the RFC author shou=
ld&nbsp;</div><div>then acknowledge the violation in a reply, wait a lit=
tle more and then&nbsp;</div><div>pre-announce the vote at a later point=
. Violations of the&nbsp;</div><div>pre-announcement period should be re=
cognized when starting the vote and&nbsp;</div><div>the RFC author shoul=
d then acknowledge the violation, cancel the vote&nbsp;</div><div>and re=
start it after a new pre-announcement (with a new title to clear&nbsp;</=
div><div>out any votes). The Wiki tracks the time of voting, so any vote=
s cast&nbsp;</div><div>after the voting period has ended would be ignore=
d (which would only&nbsp;</div><div>really matter in cases of close vote=
s).</div></blockquote><div><br></div><div>I think the more you make a po=
licy pedantic, the easier it is to play pedantic games. I had a couple o=
f hours to sit on the train and think through some loopholes in the curr=
ent proposed text:</div><div><br></div><ol><li>The 336 hours is oddly sp=
ecifc. It also begs the question: "what about leap seconds?" Could someo=
ne cause an entire revote simply by pointing out that the vote closed on=
e second earlier than 336 hours because one of those hours had one less =
second? Does it matter? Perhaps saying "~336 hours" to drive the intent =
home without saying "exactly" that amount of time?</li><li>Just about an=
y change could be construed as an "obvious typo" or "editorializing" A s=
tronger definition could be "any change that clarifies but does not alte=
r the meaning (e.g. "frrm" -&gt; "from" but not "form" -&gt; "from"), wh=
ile changes that affect APIs, semantics, or options are never typos". Ev=
en then, someone could just create a stub and simply argue that all thei=
r edits are clarifying the stub... so this one will be tricky.</li><li>F=
orbidding starting/ending on Dec 17-&gt;Jan 10 will probably backfire. I=
t would behoove someone to schedule a voting start on Dec 16, so that it=
 would end on Jan 11. Albeit, that is longer than 2 weeks, but it's shor=
ter than waiting until Jan 11 to start a vote... arguably, this is proba=
bly worse than what the rule intends to solve. If the concern is holiday=
 churn (heh, uninitentional rhyming), it might be better to forbid&nbsp;=
<i>starting</i> during that period, but let existing votes play out as n=
ormal (and maybe picking a sooner date).</li><li>The official start and =
threading is ambiguous. For example, I can add a coauthor on my RFC. The=
n "announce" the RFC by both authors but only have discussions in the la=
ter thread. I could move to a vote after two weeks, no matter what is ha=
ppening in another "unofficial" thread.</li><li>It says that you can't a=
dd or change a voting widget, but you can remove them freely without tri=
ggering a vote reset.</li><li>It might be a good idea to add "all durati=
ons are measured in UTC calendar time, ignoring leap seconds". One could=
 argue that announcing the vote at 11:59:59 Monday and starting the vote=
 at 00:00:01 Wednesday would satisfy the 2 day/48 hour rule by arguing t=
ime zone shenanigans.</li><li>If a vote ends at 15:09, does it actually =
ends at 15:09:00, or will votes be accepted until 15:09:59.99?</li><li>v=
ote extension hack: can someone change a vote end-date after the vote ha=
s already started? Thus if the results are unfavorible, can I simply jus=
t extend the voting period until I get the results I want, literally inc=
reasing it by 24 hours every day until it passes by simply stating "I am=
 still on holiday"?<br></li></ol><div><br></div><blockquote type=3D"cite=
" id=3D"qt" style=3D""><div><br></div><div>If the RFC author follows thr=
ough with a vote, despite being in&nbsp;</div><div>violation of the rule=
s and being made aware of it, the result of the&nbsp;</div><div>vote wou=
ld be void. I'd say that if no one points out the violation&nbsp;</div><=
div>after a =E2=80=9Creasonable period of time=E2=80=9D has passed, the =
violation is&nbsp;</div><div>considered to not have occurred (i.e. it sh=
ould not be possible to void&nbsp;</div><div>a vote at day 13 of the vot=
ing period).</div><div><br></div><div>Best regards</div><div>Tim D=C3=BC=
sterhus</div><div><br></div></blockquote><div><br></div><div>The new rul=
es could allow some creative people to bypass the cooldown period altoge=
ther:</div><ol><li>Someone could create an empty RFC, and announce it. T=
hen "clarify" and "editorialize" the RFC (easier to do with a coauthor t=
o back you up) minutes before the two weeks elapse, then call a vote, wi=
th most people having long dismissed the empty RFC as junk.</li><li>You =
could simply create a v2 of an RFC minutes/days after the failed vote an=
d go straight to a vote; claiming the cooldown started from the original=
 RFC.</li></ol><div>My point, hopefully, is that the more specific you a=
re, the more wiggle room people actually have both to attack and defend.=
 At the end of the day, this is a people problem, not a policy problem. =
It's one thing to clarify, but another to specify.</div><div><br></div><=
div id=3D"sig121229152">=E2=80=94 Rob</div></body></html>
--47af7c0f1b3b430eab6484b7810ab03c--