What to do with "invalid" bug reports?
Most bug trackers let you mark bugs as "invalid": the reported behavior was a result of local developer error; the reported behavior is expected; etc. What should I do with "invalid" bugs in Tracker? It feels wrong to put them through the Finished -> Deliver -> Accept states, when none of those things actually happened. It feels *very* wrong to just delete the bug, because that reduces searchability, which may lead to someone incorrectly reporting the bug again.
Note that this is not a complaint; I really just want to know what people do. If the answer is "use an external bug tracker and point the Tracker bugs at it", my question still stands: I want to keep the invalid bug in Tracker for searchability, so how should I mark it?
Thanks. :)
Note that this is not a complaint; I really just want to know what people do. If the answer is "use an external bug tracker and point the Tracker bugs at it", my question still stands: I want to keep the invalid bug in Tracker for searchability, so how should I mark it?
Thanks. :)
2
people have this question
I have this question, too!
Tell me when someone answers.
The more people who ask this question, the more it gets noticed.
The more people who ask this question, the more it gets noticed.
-
Inappropriate?I recommend you add a label "not a bug", add a comment on why you think it is not a bug and move the story to the delivered state. At that point, the story requester can agree that it is not a bug and accept the story or reject the story stating why they still think it is a bug.
1 person says
this answers the question
-
I'll take it! :) The accept/reject states do make sense; I just wasn't thinking about them properly. Thanks! -
Inappropriate?It seems the state machine of a bug, chore and story are all different. Bugs should have some standard bug related states, including, not a bug, and duplicate (with possible ability to merge or show which bug it duplicates).
-
Inappropriate?I think Pivotal should provide a set of statuses that are available based on the fact that the story is a bug and not a feature. If anything, an Accepted bug sounds like it has been agreed that it is a valid issue. This is how we're doing it currently to work with the functionality provided but it doesn't fit in with traditional tracking for defects and muddies the water if we ever did want to do metrics since "accepted" is the same status that QA would set if the bug were retested and confirmed as fixed.
Loading Profile...


