Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128724
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Thu, 25 Sep 2025 00:02:17 +0200
To: internals@lists.php.net
Message-ID: <1a9046bf-2dcc-4049-b1e7-e82d4230b0f6@app.fastmail.com>
In-Reply-To: <92a59844e30a9ca0550456886913fdb1@bastelstu.be>
References: <53cdbf5b-7c6e-4ba1-9987-332634cab527@bastelstu.be>
 <29c9d6cfcc2928d3805596416edbff6e@bastelstu.be>
 <92a59844e30a9ca0550456886913fdb1@bastelstu.be>
Subject: Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules
Content-Type: multipart/alternative;
 boundary=c945f5ec777548d796789a5305ab81ac
From: rob@bottled.codes ("Rob Landers")

--c945f5ec777548d796789a5305ab81ac
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Wed, Sep 24, 2025, at 09:09, Tim D=C3=BCsterhus wrote:
> Hi
>=20
> Am 2025-09-19 10:55, schrieb Tim D=C3=BCsterhus:
> >> Please find the RFC at:=20
> >> https://wiki.php.net/rfc/rfc_discussion_and_vote
> >> And the PR at: https://github.com/php/policies/pull/23
> >=20
> > If you followed along the discussion, you might've seen that Larry=20
> > offered to improve the phrasing of the policy for clarity. This has=20
> > happened now and I think Larry did a great job at improving the=20
> > structure of the policy text, while still using precise language and=20
> > preserving the intended semantics. He made some changes to the polic=
y=20
> > as part of the rephrasing and I agree with them all. Specifically:
>=20
> I just realized that the RFC text was not strictly following the lates=
t=20
> policy in the PR, the explanation of the voting widget was missing (=E2=
=80=9CAll=20
> voting widgets on the RFC MUST include all relevant details for that=20
> vote, as described in the "Required Majority" section below=E2=80=9D).=
 I have=20
> just added that (=E2=80=9CPrimary Vote requiring a 2/3 majority to acc=
ept the=20
> RFC:=E2=80=9D) and will also make sure to include that in the RFC temp=
late,=20
> should this RFC be accepted.
>=20
> I'm treating this change to the RFC text as a =E2=80=9CMinor change=E2=
=80=9D, since it's=20
> basically just clarification. It's implied by the existing policy that=20
> the single voting widget is a primary vote and that it requires a 2/3=20
> majority.
>=20
> All that said, I'm happy to hear some feedback on whether or not the=20
> updated phrasing is looking good to you? :-)
>=20
> Best regards
> Tim D=C3=BCsterhus
>=20

Hi Tim,

This goes back to what I was saying: pretty much any change can be justi=
fied as =E2=80=9Ca clarification=E2=80=9D by an author. We can choose to=
 accept the implication of a 2/3 majority, or challenge it.

That being said, I agree with you. But it=E2=80=99s still worth pointing=
 out that this can be abused and there isn=E2=80=99t much recourse.

I also noted you changed the text to mention that a vote can basically b=
e restarted for any reason. This would allow an unscrupulous person to b=
asically restart a vote if it isn=E2=80=99t going in the direction they =
want, without any reason other than an =E2=80=9Cissue=E2=80=9D with the =
RFC. This means they can rely upon attrition to eventually pass an RFC t=
hat would otherwise not pass, bypassing the current =E2=80=9Cone year or=
 with major changes=E2=80=9D rule.

For example, the nested classes RFC was clearly not going to pass. Had t=
his policy existed, taking what feedback I had already gotten, I could h=
ave simply declared =E2=80=9Can issue=E2=80=9D and updated it with their=
 feedback; restarting the vote. I personally wouldn=E2=80=99t do that, b=
ut this would explicitly allow that behavior.=20

=E2=80=94 Rob
--c945f5ec777548d796789a5305ab81ac
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv><br></div><div>On Wed, Sep 24, 2025, at 09:09, Tim D=C3=BCsterhus wro=
te:</div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>Hi</div><di=
v><br></div><div>Am 2025-09-19 10:55, schrieb Tim D=C3=BCsterhus:</div><=
div>&gt;&gt; Please find the RFC at:&nbsp;</div><div>&gt;&gt;&nbsp;<a hr=
ef=3D"https://wiki.php.net/rfc/rfc_discussion_and_vote">https://wiki.php=
.net/rfc/rfc_discussion_and_vote</a></div><div>&gt;&gt; And the PR at:&n=
bsp;<a href=3D"https://github.com/php/policies/pull/23" class=3D"">https=
://github.com/php/policies/pull/23</a></div><div>&gt;&nbsp;</div><div>&g=
t; If you followed along the discussion, you might've seen that Larry&nb=
sp;</div><div>&gt; offered to improve the phrasing of the policy for cla=
rity. This has&nbsp;</div><div>&gt; happened now and I think Larry did a=
 great job at improving the&nbsp;</div><div>&gt; structure of the policy=
 text, while still using precise language and&nbsp;</div><div>&gt; prese=
rving the intended semantics. He made some changes to the policy&nbsp;</=
div><div>&gt; as part of the rephrasing and I agree with them all. Speci=
fically:</div><div><br></div><div>I just realized that the RFC text was =
not strictly following the latest&nbsp;</div><div>policy in the PR, the =
explanation of the voting widget was missing (=E2=80=9CAll&nbsp;</div><d=
iv>voting widgets on the RFC MUST include all relevant details for that&=
nbsp;</div><div>vote, as described in the "Required Majority" section be=
low=E2=80=9D). I have&nbsp;</div><div>just added that (=E2=80=9CPrimary =
Vote requiring a 2/3 majority to accept the&nbsp;</div><div>RFC:=E2=80=9D=
) and will also make sure to include that in the RFC template,&nbsp;</di=
v><div>should this RFC be accepted.</div><div><br></div><div>I'm treatin=
g this change to the RFC text as a =E2=80=9CMinor change=E2=80=9D, since=
 it's&nbsp;</div><div>basically just clarification. It's implied by the =
existing policy that&nbsp;</div><div>the single voting widget is a prima=
ry vote and that it requires a 2/3&nbsp;</div><div>majority.</div><div><=
br></div><div>All that said, I'm happy to hear some feedback on whether =
or not the&nbsp;</div><div>updated phrasing is looking good to you? :-)<=
/div><div><br></div><div>Best regards</div><div>Tim D=C3=BCsterhus</div>=
<div><br></div></blockquote><div><br></div><div>Hi Tim,</div><div><br></=
div><div>This goes back to what I was saying: pretty much any change can=
 be justified as =E2=80=9Ca clarification=E2=80=9D by an author. We can =
choose to accept the implication of a 2/3 majority, or challenge it.</di=
v><div><br></div><div>That being said, I agree with you. But it=E2=80=99=
s still worth pointing out that this can be abused and there isn=E2=80=99=
t much recourse.</div><div><br></div><div>I also noted you changed the t=
ext to mention that a vote can basically be restarted for any reason. Th=
is would allow an unscrupulous person to basically restart a vote if it =
isn=E2=80=99t going in the direction they want, without any reason other=
 than an =E2=80=9Cissue=E2=80=9D with the RFC. This means they can rely =
upon attrition to eventually pass an RFC that would otherwise not pass, =
bypassing the current =E2=80=9Cone year or with major changes=E2=80=9D r=
ule.</div><div><br></div><div>For example, the nested classes RFC was cl=
early not going to pass. Had this policy existed, taking what feedback I=
 had already gotten, I could have simply declared =E2=80=9Can issue=E2=80=
=9D and updated it with their feedback; restarting the vote. I personall=
y wouldn=E2=80=99t do that, but this would explicitly allow that behavio=
r.&nbsp;</div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob</div=
></body></html>
--c945f5ec777548d796789a5305ab81ac--