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