4 ms·

I agree with this, too. Which opens up a nice point of discussion: closing stale bugs is bad because it sweeps the issue under the rug; but closing them is good

by j1elo 5y ago

I agree with this, too. Which opens up a nice point of discussion: closing stale bugs is bad because it sweeps the issue under the rug; but closing them is good in case the context and source code around the issue has changed a lot. In this case I'm not sure what's the best solution. I have suffered myself finding an open bug but so old that it didn't really apply any more. However in those cases, it has happened that attracting attention from a dev, or just testing by myself, has driven the conversation into quickly realizing that the issue didn't apply any more with current state of the source code... Maybe it's a good idea having the feature of specifying which version the bug was reported against. GitHub doesn't have this, but I've seen it in some other bug trackers.

toast0 5y ago
In an ideal world, someone would go over the open bugs on some timeline and mark them as no longer an issue, still an issue, don't know, or won't fix. An easy timeline to specify would be take a look 3 months after last activity and double the wait every time. Of course, that takes time and effort and some bugs are harder to evaluate than others.
- skybrian 5y ago
  Typically this gets bounced back to the person who reported the bug and if they don’t care (and why should they if they moved on) then nobody does it.