3 ms·

> There is one good argument in its favor [closing tickets that are too old]: the software continuously changes and hence old issues may be invalid. In order to

> There is one good argument in its favor [closing tickets that are too old]: the software continuously changes and hence old issues may be invalid. In order to put them into a sprint, they need to be checked—in some cases, that’s actually more work than the issue itself. I agree this is sometimes true, those difficult to reproduce tickets often mysteriously disappear when you make other changes. But there are lots of times when a lot of work has gone into creating the ticket so there is actually not much left to do to fix the issue. In this case closing tickets that get too old would be very counter-productive.

agloeregrets 6y ago
For a pretty crazy take on this, take. A look at BaseCamp’s “Shape Up” philosophy, They do not have a backlog. Period. To them, they work a little slower and expect to give enough time to a task to ensure zero bugs instead but then have cycles of bug-fix focus. Additionally, something I found interesting is that every dev is expected to understand the complete stack, that way any dev can fix any corner. Sure this might not work in a larger company without strong levels of splitting up the product, but It’s an enjoyable thing to look at.
jayd16 6y ago
If an issue is getting added to or starred or commented on then its not old.
kazinator 6y ago
A bug should identify where it was introduced. If a bug was introduced in version 0.5, then version 0.5 forever has that bug, and so the issues is forever valid in that sense, as a truthful comment about a historic thing. If the current version is 1.2, and it has not been confirmed to have fixed the bug, the view should be taken that the bug still exists in 1.2. Bugs don't just become invalid; if we are justified in calling a bug invalid now, that can only be because it was never valid in the first place. Suppose that someone tries to check, but the bug doesn't reproduce in 1.2. However, it was never root-caused. All we have is a description of the behavior that was happening in 0.5. Now what? Do you just close that bug to get the open bug count down? Probably an "unsolved mysteries" or "cold cases" category would be more appropriate for it rather than lumping it with genuinely closed bugs: those that were traced to a root-cause and confirmed. In cases when you're sure that the bug was due to some software that was entirely rewritten such that the same bug cannot plausibly be in the rewritten version, or some software that was removed entirely, then there is justification in closing that.
- Almad 6y ago
  As mentioned, this is true for versioned software, not for continuously deployed SaaS.

agloeregrets 6y ago

For a pretty crazy take on this, take. A look at BaseCamp’s “Shape Up” philosophy, They do not have a backlog. Period. To them, they work a little slower and expect to give enough time to a task to ensure zero bugs instead but then have cycles of bug-fix focus. Additionally, something I found interesting is that every dev is expected to understand the complete stack, that way any dev can fix any corner. Sure this might not work in a larger company without strong levels of splitting up the product, but It’s an enjoyable thing to look at.

jayd16 6y ago

If an issue is getting added to or starred or commented on then its not old.

kazinator 6y ago

A bug should identify where it was introduced. If a bug was introduced in version 0.5, then version 0.5 forever has that bug, and so the issues is forever valid in that sense, as a truthful comment about a historic thing. If the current version is 1.2, and it has not been confirmed to have fixed the bug, the view should be taken that the bug still exists in 1.2. Bugs don't just become invalid; if we are justified in calling a bug invalid now, that can only be because it was never valid in the first place. Suppose that someone tries to check, but the bug doesn't reproduce in 1.2. However, it was never root-caused. All we have is a description of the behavior that was happening in 0.5. Now what? Do you just close that bug to get the open bug count down? Probably an "unsolved mysteries" or "cold cases" category would be more appropriate for it rather than lumping it with genuinely closed bugs: those that were traced to a root-cause and confirmed. In cases when you're sure that the bug was due to some software that was entirely rewritten such that the same bug cannot plausibly be in the rewritten version, or some software that was removed entirely, then there is justification in closing that.

Almad 6y ago
As mentioned, this is true for versioned software, not for continuously deployed SaaS.