I'm defining a new defect workflow and would like to understand why one would have a separate ReOpen status vs Open. Is there advantages to treat ReOpen as a separate state beyond reporting (which could be achieved in a different manner). Defects that fail QA verifiction move back to InProgress so ReOpen is really used when defect is reintroduced or not truely fixed.
Thoughts?
It depends on your real life practices. Some teams find a re-open status useful or even essential. Others find it useless. In your case, it sounds mostly like you don't need re-open, but a totally different status like "QA fail".
There's a similar, longer discussion from yesterday at https://answers.atlassian.com/questions/145543/how-it-is-better-to-mark-deferred-issues-as-a-state-or-as-a-resolution-for-the-closed-state-in-jira-workflows?page=1#145567
p.s. >Another solution would be to disallow re-open - that is a terrible practice, in most cases. If you are having the same problem over and over, you want to know about it, and having disparate issues screams "we aren't dealing with it, we're ignoring our users". You simply miss the fact that something keeps happening.
Every new status you add is that much more time your users spend in JIRA and less time doing the actual work. It's also that much more education they'll likely require to know what each status means and how it applies to them.
In my opinion a "Re-open" status would be overkill. JIRA can already tell you how many times an issue has been in a particular status. You can use this information to your advantage so that you know how many times it was re-opened.
Another solution would be to disallow issues to be reopened. Instead, new issues must always be created.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.