Basically every single old bug report I've ever seen is essentially a red-herring that is usually not able to be reproduced anymore after N years and takes away time from focusing on newer and more solvable issues. I don't see the issue with removing that noise if it's no longer being reported, but to each their own I suppose.
Sure. So try to reproduce on a current build, and close with a "No longer reproduceable on ___". That'd be good practice. Closing silently because no one can be bothered to evaluate at all is horrendous, and creates the user expectation that "no one looks at these, so I'm not going to keep reporting it" which "justifies" developers closing old bugs.
I agree with you about that, but why would an ill-defined report be kept open in the first place? It shouldn't be. Give the user an opportunity to provide more detail - for my own use I have some auto-text "scripts" set up, to make prompt questions easy - and then auto-close after a few days.
[Edit, answering my own question: they're left open because they were ignored to begin with.]
I write excellent bug reports, the vast majority of which (I'm thinking of one service-provider in particular, may they live in shame) get ignored. Or escalated and ignored; somehow that feels worse, though I don't know if it should. I guess it's the hope. It's the hope that kills you.
Every other month I get an email from a legacy pre-GH bug tracker that's either a "me too" or "bug fixed in latest release" a decade after I filed these one-offs you would be so quick to throw away. Bugs with no activity for years on end.
the right thing to do is to actually ping the original reporter if possible, or a developer that you might assign the bug to and try to drive it to a conclusion.
if the answer is 'everything in that part of the code has been rewritten' or 'yeah, that was a dup, we fixed that' or 'there isn't enough information here to try to reproduce it even if we wanted to' or 'this a feature request that we would never even consider' or some other similar thing, then sure delete it.
otherwise you're just throwing away useful information.
edit: I think this difference of option is due to a cultural difference between (a) the software should be as correct as reasonably possible and (b) if no one is complaining then there isn't a problem
Closing bugs because of a rewrite is probably the most harmful practice in the whole industry. The accumulated unresolved issues of your existing code base are a rich resource of test cases. Writing the new code base without checking to see if it fixes the old bugs is a mistake.
sure. But you can say put "please verify whether it is still present" via bot before doing so. Which apple did and I'm not sure why blogpost author is complaining about that
> you can say put "please verify whether it is still present" via bot before doing so. Which apple did
No, that's not what Apple did. They said, "Please verify this issue with macOS 26.4 beta 4", a very specific version, implying that they actually fixed the bug in that specific beta version (spoiler: they didn't). And I would have to go out of my way to install that specific beta just to "verify" the bug. Moreover, they gave me only 2 weeks to verify before closing the bug that they hadn't responded to at all in 3 years.
They suddenly created artificial urgency for no apparent reason.
That only works if the "please verify" bot isn't just prodding for noise and then autoclosing anyway, which is exactly what the author keep running into, over and over, even when the report already has enough detail to reproduce it.
Worse, they ask again after a video.
If you want signal, add a flag or make verification mean something in triage, not just another loop.
As set up now, you're rewarded more for patience than for actually fixing teh issue at all.
