Re: [RFC] Clarify discussion and voting period rules

On Thu, Sep 25, 2025, at 3:14 AM, Nick wrote: >> On 25. Sep 2025, at 05:02, Rob Landers <rob@bottled.codes> 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