> On 19. Jul 2025, at 22:46, Niels Dossche <dossche.ni...@gmail.com> wrote: > > Op zaterdag 19 juli 2025 schreef Rob Landers <rob@bottled.codes>: > > On Fri, Jul 18, 2025, at 14:10, Tim Düsterhus wrote: > > > > Hi > > Apologies for the belated reply. I was busy with getting my own > > implementation wrapped up and the thread was so active that I had > > troubles keeping up. > > > > Hi Tim, > > Thanks for taking the time to reply. That said, I would like to address a > > concern, not about the content of your message, but the timing. > > On multiple RFCs, you've joined in once the discussions has wound down and > > a vote is immeninent. At this point, many participants have assumed the key > > issues are raised and addressed; or at least, reached the point of > > constructive impasse. > > Hey > > To be honest, I find your email a bit strange, perhaps even misdirected. As > someone who followed this discussion more quietly, it is absolutely not my > impression that the discussion wounded down already. > > > Reopening settled threads so close to vote tends to disrupt the process. It > > forces others to revisit old arguments under time pressure, giving the late > > comments disproportionate visibility, and risks stalling momentum. > > It wasn't closed, so there isn't anything to reopen. Also may I remind you > that the call for an impeding vote is the thing that triggers time pressure, > not Tim's reply. > The goal of having an RFC discussion should be to get consensus during the > discussion phase. > > > I understand that threads move quickly and schedules vary, but if a concern > > is important enough to raise, it really helps to do so while the > > discussions are actively evolving. Otherwise, it becomes difficult to > > engage meaningfully. > > He did raise it. > > Keeping track of the entire ML discussions is hard, and also difficult > time-wise. Tim is one of the people who tries to participate to basically > every RFC, doing his part in making sure we end up with the best possible > outcome for a feature. I'd call that meaningful. I'd also rather delay a > feature than having something sooner that we didn't stand behind completely. > > > At a certain point, late feedback stops being helpful and starts to erode > > the trust and rhythm of the process. > > I wouldn't call it late. > Rushing this RFC to vote to get it into 8.5, despite there being no clear > consensus, is the thing that erodes trust and breaks the rythm of the process. > > > — Rob > > Kind regards > Niels
Hey Niels, In before: I personally didn’t have a problem with Tim joining in late. I, however, want to express that I don’t feel anything productive happens at this point. My personal impression is, there wasn’t anything new added since the early beginning of the discussion. Everything was brought up early on. If you believe that’s not the case and I missed something, please point me to the new arguments. So, calling it “not wound down” feels off to me. And that’s why I answer now. As someone who is a new participant here, please allow me to ask: When is a discussion allowed to be considered wound down? And, is repeating the same arguments (just by different persons) really a reason to keep a discussion going? The whole controversy is about `get`. We addressed this by switching to a split vote, because literally all those concerns/opinions (allow it; don’t allow it; add `init` instead; cache it; don’t cache it) can for now be “addressed” with a “no”-vote on `get`, and then follow up with a new `get` RFC later. Am I wrong? What is this all about now? What are we doing now? Do we keep repeating the same arguments, and disallow bringing this to vote at all? Even though like literally everyone seems to be on board with “`set` is ok”? Or are we allowed to move on with a vote? > despite there being no clear consensus The clear consensus seems to be that `set` should be allowed. That’s why we adjusted the vote. I repeat: everyone with a problem (any kind) on `get` can vote “no” on `get` and “yes” on `set`. — Again, this is nothing specifically towards Tim. Cheers, Nick
