Why issue tracker systems usually have distinct "Opened" and "Reopened" statuses?
Issues which are Open are generally first occurrence of whatever issue it is.
Issues which are re-openned are either 1) re-occurring and/or 2) not fixed properly. There may be any number of reasons for that - a key one may often be linked to the original description of the issue to the end user.
I don't think any sensible shop would use it as a metric to judge technical staff [alone] but it is useful as a measure to identify how effective responses are, and may also signify underlying problems which need to be addressed.
The lifetime of a bug is often:
- (Optional) Re-Opened
- (Optional) Go To: 3
Someone finds a bug and opens it in the tracker. The dev fixes it as best they can with their understanding of the problem. Tester re-tests to verify the fix worked and re-opens if they can verify that it didn't. If the fix is verified then the bug is closed.
The other scenario, is that a fix somewhere else caused a regression and the bug has to be re-fixed. Thus, it is re-opened.
Opened means it is a new issue. Reopened meanse ti was an issue which was Opened->Clossed and then Opened again.
Why was it opened again? Maybe the developer and tester thought that issue was fixed but it wasn't really fixed. Or maybe the issue was really fixed but some other subsequent code changes caused the issue to reoccur. It doesn't matter how but a re-opened issue is a bad sign and hence it is categorized differently.
The way we use it here:
New Task: Created at the start of the project to show all work that needs to be done. It is open until someone codes it, then it is resolved. It is only reopened if something wasn't implemented, or if the functionality changed and the developer has to go back and spend a good chunk of time working on it.
Bug/Defect: Opened by someone in QA or another dev checking the overall working product. If you are assigned a bug, you fix it and then resolve it and it goes back into testing. If the QA feels it hasn't been fixed they will reopen it and attach any other info they have to it. The Resolved/Reopened cycle can go until QA is satisfied that the bug has been fixed, then they close the ticket.
So, basically you use Reopen to say that a ticket has already been looked at and someone has done work on it that they felt resolved it, but that wasn't the case.
It's basically a consistency type of thing: A bug (or an issue in general) is "open" if it has been created from scratch. It is "reopen" if is has been created after a previous processing has been performed.
For a developer (or anyone handling the issue) it shouldn't make any difference. An issure has been raised and should now be processed.
However a distinct "reopen" status can still be useful for a number of scenarios:
First, it can be used as a way of tracking whether or not your quality assurance process works. If the QA did everything right, a bug should never occur after it has been fixed. So, you could say the number of times a bug has been set into the "reopen" state is the number of times the QA hasn't quite done it's job properly. This of course implies that there is a good QA process established and that the users actively participate in the process and know when to "open" and when to "reopen" an issue.
Another use is that, when a bug happens again, you do not need to rais eanother issue but can add the information an already existing issue (and therefore keep important information like the issues history, additional files that have been uploaded, previous comments, and so on) but still indicate "hey, this happend again).
One main reason for tracking "reopen" is that it can give you an indication of deep routed problems, rather than simple slipups and oversight of detail. If a particular module or piece of functionalty has numerous "repopens", it points to a weakness that needs addressing. A large number of single opens points to rushed work and/or sloppy practice.