On Thu, Sep 25, 2025, at 3:14 AM, Nick wrote: >> On 25. Sep 2025, at 05:02, Rob Landers <[email protected]> wrote: >> >> 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. >> >> 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. >> >> — Rob > > > Hey, > > I am wondering if this is actually a bad thing. > I’d argue if a RFC is evolving until it passes it does good for the language. > > Maybe such "in between votes” could help to gather sentiment in > complicated, lengthy discussions? > Author tries, sees that it likely will not succeed, goes back to > discussion, refines, starts vote again. > > There would need to be clear rules for that too, of course. Maybe > 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 doomed, I don't see an issue with the author going "eh, never mind" and saving everyone 2 weeks of waiting. If there's some key controversial bit they can change and try again, I think that's reasonable. Probably needs 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
