4 ms·

Here's something that bugs me: Whenever I release a new version of something, non-closed bugs should be tagged as "review", to check if the problem has solved i

Here's something that bugs me: Whenever I release a new version of something, non-closed bugs should be tagged as "review", to check if the problem has solved itself (e.g. by updating to a new library that was used somewhere else)

capableweb 6y ago
On the surface, it sounds like a good idea. When thinking about it further, I think this is solving the wrong problem. Bugtrackers usually (in my experience, after 1-2 years on a project) end up with thousands of tickets, too many of them open. If after every release, you have to re-check all of them, the QA department (or whoever will do the review) will spend all their time reconfirming bugs that the engineers could easily have said "Yes, still an issue" or "Nope, fixed" after just glancing on it, compared to a tester who might not understand all the code changes. Instead, aggregating information and making your bug tracker "clean" should help engineers knowing what's open and what's been fixed, and when doing a new release version, they should know exactly what has been fixed already.
Koffiepoeder 6y ago
You can do stuff like that with jira automations. Yes, I know, I too despise jira for its 20MB pageloads, horrible UX and hundreds of main-thread blocking requests. But that's not the point here. So, if you happen to use jira - as unpleasant as it may be - it's probably best to just deal with it and use it to its fullest potential ;-)
avinashjn 6y ago
As capableweb has pointed out, all of us have been there with the 1000+ bugs overflowing from the previous sprints/releases. While its important to fix these issues, I don't think it actually happens anywhere. Another approach might be to 'carry over' the CRITICAL or HIGH issues only. This way, there is lesser carry over and the team won't be bogged down.
- mst 6y ago
  "Confirmed" versus "Re-confirmed" and some UI way to interact with that perhaps

capableweb 6y ago

On the surface, it sounds like a good idea. When thinking about it further, I think this is solving the wrong problem. Bugtrackers usually (in my experience, after 1-2 years on a project) end up with thousands of tickets, too many of them open. If after every release, you have to re-check all of them, the QA department (or whoever will do the review) will spend all their time reconfirming bugs that the engineers could easily have said "Yes, still an issue" or "Nope, fixed" after just glancing on it, compared to a tester who might not understand all the code changes. Instead, aggregating information and making your bug tracker "clean" should help engineers knowing what's open and what's been fixed, and when doing a new release version, they should know exactly what has been fixed already.

Koffiepoeder 6y ago

You can do stuff like that with jira automations. Yes, I know, I too despise jira for its 20MB pageloads, horrible UX and hundreds of main-thread blocking requests. But that's not the point here. So, if you happen to use jira - as unpleasant as it may be - it's probably best to just deal with it and use it to its fullest potential ;-)

avinashjn 6y ago

As capableweb has pointed out, all of us have been there with the 1000+ bugs overflowing from the previous sprints/releases. While its important to fix these issues, I don't think it actually happens anywhere. Another approach might be to 'carry over' the CRITICAL or HIGH issues only. This way, there is lesser carry over and the team won't be bogged down.

mst 6y ago
"Confirmed" versus "Re-confirmed" and some UI way to interact with that perhaps