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
