3 ms·

> There are finite resources, true. So keep the tickets open. Eventually someone will fix them. Realistically, no, they won't. If the rate of new P0-P2 bugs is

by lmm 2y ago

> There are finite resources, true. So keep the tickets open. Eventually someone will fix them. Realistically, no, they won't. If the rate of new P0-P2 bugs is higher than the rate of fixing being done, then the P3 bugs will never be fixed. Certainly by the time someone gets around to trying to fix the bug, the ticket will be far enough out of date that that person will not be able to trust it. There is zero value in keeping the ticket around. > Anything else is supporting a lie. Now who's prioritising "spurious psychological reasons" over the things that actually matter? Closing the ticket as wontfix isn't denying that the bug exists, it's acknowledging that the bug won't be fixed. Which is much less of a lie than leaving it open.

lesuorac 2y ago
But then when somebody else has the issue they make a new bug and any data/investigation from the old one is basically lost. Like what's wrong with having 1000 open bugs?
- Arainach 2y ago
  In becomes functionally impossible to measure and track tech debt. Not all of those issues are tech debt - things which will never be fixed don't matter. Put another way: you're working on a new version of your product. There are 900 issues in the tracker. Is this an urgent emergency where you need to shut down feature work and stabilize? If you keep a clean work tracker where things that are open mean work that should get done: absolutely If you just track everything ever and started this release with 1100 issues: no, not necessarily. But wait, of those 900 issues are there any that should block the release? Now you have 900 to go through and determine. And unless you won't fix some of them you'll have the same thing in a few months. Work planning, triage, and other team tasks are not magic and voodoo, but on my experience the same engineers who object to the idea of "won't fix" are the ones who want to just code all day and never have to deal with the impact of a huge messy issue database on team and product.
  - kelnos 2y ago
    That's absurd. Closing those issues doesn't make them go away, it just causes you to forget them (until someone else reports them again and someone creates a new issue, losing all the previous context). If you just leave them open, some will eventually get fixed, many will not, and that's fine. The decision between feature work vs. maintenance work in a company is driven by business needs, not by the number of bugs open in the issue tracker. If anything, keeping real bugs open helps business leaders actually determine their business needs more effectively. Closing them unfixed is the equivalent of putting your head in the sand.
  - lesuorac 2y ago
    > Not all of those issues are tech debt - things which will never be fixed don't matter. Except that I've spent a good amount of time fixing bugs originally marked as `won't fix` because they actually became uh "will fix" (a decade later; lol). > Put another way: you're working on a new version of your product. There are 900 issues in the tracker. Is this an urgent emergency where you need to shut down feature work and stabilize? Do you not prioritize your bugs? If the tracker is full of low priority bugs then it doesn't block the release. One thing we do is even if the bug would be high priority; if it's not new (as-in occurs in older releases) it doesn't (by default) block the next release. > But wait, of those 900 issues are there any that should block the release? Now you have 900 to go through and determine. And unless you won't fix some of them you'll have the same thing in a few months. You should only need to triage the bug once. It should be the same amount of work to triage a bug into low-priority as it is to mark it as `won't fix`. With (again), the big difference between that if a user searches for the bug they can find it and ideally keep updating the original bug instead of making a dozen new ones that need to be de-duplicated and triaged which is _more work_ not _less work_ for triagers. > Work planning, triage, and other team tasks are not magic and voodoo, but on my experience the same engineers who object to the idea of "won't fix" are the ones who want to just code all day and never have to deal with the impact of a huge messy issue database on team and product. If your idea of the product is ready for release is 0 bugs filed then that's something you're going to want to change. Every software gets released with bugs; often known bugs. I will concede that if you "stop the count" or "stop testing" then yeah you'll have no issues reported. Doesn't make it the truth.
- lmm 2y ago
  > But then when somebody else has the issue they make a new bug and any data/investigation from the old one is basically lost. You keep the record of the bug, someone searching for the symptoms can find the wontfix bug. Ideally you put it in the program documentation as a known issue. You just don't keep it open, because it's never going to be worked on. > Like what's wrong with having 1000 open bugs? Noise, and creating misleading expectations.
YokoZar 2y ago
Every once in a while I get an email about a ten plus year old bug finally getting fixed in some open source project. If it's a good bug accurately describing a real thing, there's no reason to throw that work away rather than just marking it lower priority.
- lmm 2y ago
  > If it's a good bug accurately describing a real thing, there's no reason to throw that work away rather than just marking it lower priority. Perhaps. But the triage to separate the "good bugs accurately describing real things" from the chaff isn't free either.
  - mithametacs 2y ago
    Storage is cheap, database indexes work. Just add a `TimesChecked` counter to your bug tracker. Now when considering priorities, consider not just impact and age, but also times checked. It's less expensive than going and deleting stuff. Unless you're automating deletions? In which case... I don't think I can continue this discussion.
    - lmm 2y ago
      In what world is adding a custom field to a bug tracker and maintaining it cheaper than anything? If someone proves out this workflow and releases a bug tracker that has the functionality built in then I'll consider adopting it, but I'm certainly not going to be the first.
      - mithametacs 2y ago
        Wild. Okay, keep deleting bug tickets.
    - Arainach 2y ago
      We already have a TimesChecked counter: If (status != Active) { /* timesChecked > 0 */ }
kelnos 2y ago
> If the rate of new P0-P2 bugs is higher than the rate of fixing being done, then the P3 bugs will never be fixed. That's quite a big assumption. Every company I've worked at where that was the case had terrible culture and constantly shipped buggy crap. Not really the kind of environment that I'd use to set policy or best practices.
- lmm 2y ago
  If you're in the kind of environment where you fix all your bugs then you don't have a ballooning bug backlog and the problem never arises. I've worked in places that fixed all their bugs, but to my mind that was more because they didn't produce the kind of product that has P3 bugs than because they had better culture or something.

by lmm 2y ago

lesuorac 2y ago

But then when somebody else has the issue they make a new bug and any data/investigation from the old one is basically lost. Like what's wrong with having 1000 open bugs?

Arainach 2y ago
In becomes functionally impossible to measure and track tech debt. Not all of those issues are tech debt - things which will never be fixed don't matter. Put another way: you're working on a new version of your product. There are 900 issues in the tracker. Is this an urgent emergency where you need to shut down feature work and stabilize? If you keep a clean work tracker where things that are open mean work that should get done: absolutely If you just track everything ever and started this release with 1100 issues: no, not necessarily. But wait, of those 900 issues are there any that should block the release? Now you have 900 to go through and determine. And unless you won't fix some of them you'll have the same thing in a few months. Work planning, triage, and other team tasks are not magic and voodoo, but on my experience the same engineers who object to the idea of "won't fix" are the ones who want to just code all day and never have to deal with the impact of a huge messy issue database on team and product.
- kelnos 2y ago
  That's absurd. Closing those issues doesn't make them go away, it just causes you to forget them (until someone else reports them again and someone creates a new issue, losing all the previous context). If you just leave them open, some will eventually get fixed, many will not, and that's fine. The decision between feature work vs. maintenance work in a company is driven by business needs, not by the number of bugs open in the issue tracker. If anything, keeping real bugs open helps business leaders actually determine their business needs more effectively. Closing them unfixed is the equivalent of putting your head in the sand.
- lesuorac 2y ago
  > Not all of those issues are tech debt - things which will never be fixed don't matter. Except that I've spent a good amount of time fixing bugs originally marked as `won't fix` because they actually became uh "will fix" (a decade later; lol). > Put another way: you're working on a new version of your product. There are 900 issues in the tracker. Is this an urgent emergency where you need to shut down feature work and stabilize? Do you not prioritize your bugs? If the tracker is full of low priority bugs then it doesn't block the release. One thing we do is even if the bug would be high priority; if it's not new (as-in occurs in older releases) it doesn't (by default) block the next release. > But wait, of those 900 issues are there any that should block the release? Now you have 900 to go through and determine. And unless you won't fix some of them you'll have the same thing in a few months. You should only need to triage the bug once. It should be the same amount of work to triage a bug into low-priority as it is to mark it as `won't fix`. With (again), the big difference between that if a user searches for the bug they can find it and ideally keep updating the original bug instead of making a dozen new ones that need to be de-duplicated and triaged which is _more work_ not _less work_ for triagers. > Work planning, triage, and other team tasks are not magic and voodoo, but on my experience the same engineers who object to the idea of "won't fix" are the ones who want to just code all day and never have to deal with the impact of a huge messy issue database on team and product. If your idea of the product is ready for release is 0 bugs filed then that's something you're going to want to change. Every software gets released with bugs; often known bugs. I will concede that if you "stop the count" or "stop testing" then yeah you'll have no issues reported. Doesn't make it the truth.
lmm 2y ago
> But then when somebody else has the issue they make a new bug and any data/investigation from the old one is basically lost. You keep the record of the bug, someone searching for the symptoms can find the wontfix bug. Ideally you put it in the program documentation as a known issue. You just don't keep it open, because it's never going to be worked on. > Like what's wrong with having 1000 open bugs? Noise, and creating misleading expectations.

YokoZar 2y ago

Every once in a while I get an email about a ten plus year old bug finally getting fixed in some open source project. If it's a good bug accurately describing a real thing, there's no reason to throw that work away rather than just marking it lower priority.

lmm 2y ago
> If it's a good bug accurately describing a real thing, there's no reason to throw that work away rather than just marking it lower priority. Perhaps. But the triage to separate the "good bugs accurately describing real things" from the chaff isn't free either.
- mithametacs 2y ago
  Storage is cheap, database indexes work. Just add a `TimesChecked` counter to your bug tracker. Now when considering priorities, consider not just impact and age, but also times checked. It's less expensive than going and deleting stuff. Unless you're automating deletions? In which case... I don't think I can continue this discussion.
  - lmm 2y ago
    In what world is adding a custom field to a bug tracker and maintaining it cheaper than anything? If someone proves out this workflow and releases a bug tracker that has the functionality built in then I'll consider adopting it, but I'm certainly not going to be the first.
    - mithametacs 2y ago
      Wild. Okay, keep deleting bug tickets.
  - Arainach 2y ago
    We already have a TimesChecked counter: If (status != Active) { /* timesChecked > 0 */ }

kelnos 2y ago

> If the rate of new P0-P2 bugs is higher than the rate of fixing being done, then the P3 bugs will never be fixed. That's quite a big assumption. Every company I've worked at where that was the case had terrible culture and constantly shipped buggy crap. Not really the kind of environment that I'd use to set policy or best practices.

lmm 2y ago
If you're in the kind of environment where you fix all your bugs then you don't have a ballooning bug backlog and the problem never arises. I've worked in places that fixed all their bugs, but to my mind that was more because they didn't produce the kind of product that has P3 bugs than because they had better culture or something.