Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128733
Message-ID: <7f1bce1f-f80b-48e7-962a-539172a85a6d@bastelstu.be>
Date: Fri, 26 Sep 2025 17:18:09 +0200
Precedence: list
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules
To: Rob Landers <rob@bottled.codes>, internals@lists.php.net
References: <53cdbf5b-7c6e-4ba1-9987-332634cab527@bastelstu.be>
 <29c9d6cfcc2928d3805596416edbff6e@bastelstu.be>
 <92a59844e30a9ca0550456886913fdb1@bastelstu.be>
 <1a9046bf-2dcc-4049-b1e7-e82d4230b0f6@app.fastmail.com>
Content-Language: en-US
In-Reply-To: <1a9046bf-2dcc-4049-b1e7-e82d4230b0f6@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

On 9/25/25 00:02, Rob Landers wrote:
> This goes back to what I was saying: pretty much any change can be justified as “a clarification” by an author. We can choose to accept the implication of a 2/3 majority, or challenge it.

Absolutely, there is always some uncertainty when not treating something 
as a major change. I explicitly spelled out my reasoning when making the 
change, so that we as a community can discuss how we feel about this 
type of change and to get some discussion precedent if a similar 
situation arrives in the future.

If it would've been a secondary vote, I would've treated it as a major 
change, since in that case I would've considered that “Changing a voting 
widget”.

> I also noted you changed the text to mention that a vote can basically be restarted for any reason. This would allow an unscrupulous person to basically restart a vote if it isn’t going in the direction they want, without any reason other than an “issue” with the RFC. This means they can rely upon attrition to eventually pass an RFC that would otherwise not pass, bypassing the current “one year or with major changes” rule.

Small correction: It's just half a year before an RFC may be reproposed.

I don't think this is a significant risk: Casting a “No” is simple and I 
expect the regular folks to notice if an RFC is repeatedly restarted for 
no good reason. If it becomes clearly abusive, I would expect this to be 
treated similarly to any other case of someone being abusive on the list.

> For example, the nested classes RFC was clearly not going to pass. Had this policy existed, taking what feedback I had already gotten, I could have simply declared “an issue” and updated it with their feedback; restarting the vote. I personally wouldn’t do that, but this would explicitly allow that behavior.

I agree with both Nick and Larry that I would be okay with that: If you 
realized less than 2 days into the vote that you didn't properly take 
the feedback into account and then *do* take the feedback into account, 
I'd consider this a success story rather than a failure.

In fact we had just that for PHP 8.5. The “Add locale for case 
insensitive grapheme functions” RFC had gotten little feedback during 
the discussion and during the vote, Derick mentioned that the proposal 
was insufficient to make an educated decision. The vote was then 
canceled and later (successfully) restarted: 
https://externals.io/message/127791#127803

Best regards
Tim Düsterhus