The whole thing is less than a page long and dead simple, I'm just going to copy/paste the entire page verbatim: We also have too many internal users for our own good. at this point we are a small team with only 2 experienced devs (the rest are very good but are relatively new graduates and/or without a lot of experience and require supervision) and close to 5000 open bugs and requests, and a steady stream of new feature requests and bug reports. I also set aside time for bug grooming once in a while, closing bugs which were fixed or are no longer relevant. And occasionally, one of the very old bugs will be critical enough for a large enough group of users that it will rise up in the ratings to be fixed. Which helps a lot with the upkeep and with planning ahead. To his credit, that manager also came up with a more-or-less effective formula to rate the bugs according to their importance based on several criteria. Some of the bugs are still encountered by new users, unfortunately, but are not fixed yet since they are not critical enough or have enough impact compared to other bugs. When I got this role, I instated a culture of never closing old bugs, despite some of my managers wanting me to do that many times, and one of them even going on a rampage once and closing some of them (which I reversed as soon as he left). We still have open bugs that's 20 years old and haven't yet been fixed. I'm one of the maintainers / developers / support personnel for an internal app that was created circa 1996. (Note: also, "closed" should be subdivided into "implemented" and "rejected" with different visual statuses, like Merge Requests often are distinctly coloured by merged vs closed - but this is not a separate bin). This is far from ideal, because the filter isn't sticky, so you either have to bookmark it or continually re-apply it.īut it would be really nice if bug trackers created three visual bins to dump things into, where the middle bin is this nebulous "stuff" that's not quite groomed well enough to be actionable but also not finished enough to be closed. The best compromise for the moment seems to be leaving them open, tagging them as outdated or someday/maybe, and filtering out those tags. Also it can be rude, if it was a high effort bug report.Īt the same time, I don't want to leave open years-old issues about a part of the program which has been heavily modified, because they are likely outdated, and low priority to begin with. I think it's actually a problem with issue trackers, which have only this binary open/closed status, where the only way to express "outdated" is with a label or something.Īs a project maintainer, I don't want to close unfixed issues because they become much harder to find (hidden by default), which results in duplicate reports if it turns out the issue is not fixed. (Personally speaking in the last few months, I've gotten several good solutions from reading the commentary on defects that were closed as unfixed.) And if closing it was wrong, you'll run into the issue again, and can either re-open the defect or submit a new defect with a back link to the original, and an explanation of what's changed that's brought it back into relevance. With that point of view, closing the defect as unfixed and explaining the reasons why is in some ways more honest than just keeping the thing open ad infinitum just because somebody, at some point in the past, thought there was an issue. The fact that a bug can stay at low priority for years is a reasonable sign that it's not too important to spend a lot of effort either tracking it or fixing it. Sometimes the overhead of that maintenance work isn't worth it, particularly for a bug that's been explicitly categorized as 'low priority' for years. Having a bug on the list isn't enough - it needs to be periodically reviewed, kept up to date, prioritized, etc. The counterargument is that a bug is enough a function of its context that the older they get, the less likely they are to still be relevant or accurately documented.