4 ms·

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 docum

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. Having a bug on the list isn't enough - it needs to be periodically reviewed, kept up to date, prioritized, etc. 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. 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. 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. 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. (Personally speaking in the last few months, I've gotten several good solutions from reading the commentary on defects that were closed as unfixed.)

samus 6y ago
This assumes that the bug creator can be bothered to review the bug and type every n weeks "still happens", with n unknown and variable in general. This makes sense for an organization with clear processes where the value of n is well-known to all stakeholders, but comes off as unwelcoming and offputting for users who want to contribute in their free time to improve their favorite applications.
smichel17 6y ago
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. As 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. Also it can be rude, if it was a high effort bug report. At 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. The best compromise for the moment seems to be leaving them open, tagging them as outdated or someday/maybe, and filtering out those tags. This is far from ideal, because the filter isn't sticky, so you either have to bookmark it or continually re-apply it. But 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. (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).
- baud147258 6y ago
  with Jira workflow, it's kinda possible to do that, with a status like backlog, so the bug is open, but can easily be filtered out

samus 6y ago

This assumes that the bug creator can be bothered to review the bug and type every n weeks "still happens", with n unknown and variable in general. This makes sense for an organization with clear processes where the value of n is well-known to all stakeholders, but comes off as unwelcoming and offputting for users who want to contribute in their free time to improve their favorite applications.

smichel17 6y ago

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. As 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. Also it can be rude, if it was a high effort bug report. At 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. The best compromise for the moment seems to be leaving them open, tagging them as outdated or someday/maybe, and filtering out those tags. This is far from ideal, because the filter isn't sticky, so you either have to bookmark it or continually re-apply it. But 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. (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).

baud147258 6y ago
with Jira workflow, it's kinda possible to do that, with a status like backlog, so the bug is open, but can easily be filtered out