Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128727
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Thu, 25 Sep 2025 09:46:03 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <fafb5a7e-efe2-4024-b5c9-74e60805f06f@app.fastmail.com>
In-Reply-To: <AE3E5C12-2599-4361-9CD0-24ACF2AE175B@nicksdot.dev>
References: <53cdbf5b-7c6e-4ba1-9987-332634cab527@bastelstu.be>
 <29c9d6cfcc2928d3805596416edbff6e@bastelstu.be>
 <92a59844e30a9ca0550456886913fdb1@bastelstu.be>
 <1a9046bf-2dcc-4049-b1e7-e82d4230b0f6@app.fastmail.com>
 <AE3E5C12-2599-4361-9CD0-24ACF2AE175B@nicksdot.dev>
Subject: Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Sep 25, 2025, at 3:14 AM, Nick wrote:
>> On 25. Sep 2025, at 05:02, Rob Landers <rob@bottled.codes> wrote:
>>=20
>> This would allow an unscrupulous person to basically restart a vote i=
f 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 p=
ass, bypassing the current =E2=80=9Cone year or with major changes=E2=80=
=9D rule.
>>=20
>> For example, the nested classes RFC was clearly not going to pass. Ha=
d this policy existed, taking what feedback I had already gotten, I coul=
d have simply declared =E2=80=9Can issue=E2=80=9D and updated it with th=
eir feedback; restarting the vote. I personally wouldn=E2=80=99t do that=
, but this would explicitly allow that behavior.=20
>>=20
>> =E2=80=94 Rob
>
>
> Hey,=20
>
> I am wondering if this is actually a bad thing.
> I=E2=80=99d argue if a RFC is evolving until it passes it does good fo=
r the language.
>
> Maybe such "in between votes=E2=80=9D could help to gather sentiment i=
n=20
> complicated, lengthy discussions?
> Author tries, sees that it likely will not succeed, goes back to=20
> discussion, refines, starts vote again.
>
> There would need to be clear rules for that too, of course. Maybe=20
> maximum restarts until the 6 month rule applies?
>
> I find this worth to think about .
>
> Cheers
> Nick

I'm inclined to agree.  If within 48 hours it's obvious that an RFC is d=
oomed, I don't see an issue with the author going "eh, never mind" and s=
aving everyone 2 weeks of waiting.  If there's some key controversial bi=
t they can change and try again, I think that's reasonable.  Probably ne=
eds a Major Change cooldown period, but that's fine.

We already have a problem of discussion being a very poor quality signal=
 for how the vote will go, Once you start getting a solid signal (vote),=
 I don't have an issue with course correcting in that case.

--Larry Garfield