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.

|improve this answer|||||

My old company used those statuses to track how many times your issue went to "Reopened" to see how "bad" of a developer you were. They thought that a correlation exists between the number of times a work item gets "Reopened" and your worth as a programmer.

I don't work there anymore.

|improve this answer|||||
  • ugh, good move Robert. Anywhere that uses these type of dev metrics to judge devs is not a good place to be. – ozz May 9 '11 at 14:03
  • 1
    yeah, if you end up tracking any kind of metrics, someone will inevitably use them for evil. – Robert Greiner May 9 '11 at 14:14
  • I once read of a company that rewarded testers for bugs found, and developers for average time to fix bugs. You guessed it. Developers told testers what "bugs" to look for... once reported, they "fixed" them very quickly... – mattnz May 9 '11 at 21:30
  • @mattnz yeah, usually when you have these bullcrap type metrics, the devs/testers always find a way to tilt things in their favor. – Robert Greiner May 10 '11 at 13:01

The lifetime of a bug is often:

  1. Opened
  2. Resolved
  3. (Optional) Re-Opened
  4. Resolved
  5. (Optional) Go To: 3
  6. Closed


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.

|improve this answer|||||

It may also be to make it more obvious that the issue needs closer attention or faster attention because it continues to be a problem after the issue was believed to have been solved.

|improve this answer|||||

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.

|improve this answer|||||

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.

|improve this answer|||||

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).

|improve this answer|||||

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.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.