How it is better to mark deferred issues as a state or as a resolution for the closed state in jira workflows?

[Sorin Sbarnea (Citrix)]

Mainly I do need to introduce the Deferred state but I am not sure if it would be a better idea to add an aditional state or just to add it as an resolution type for the Closed state.

Feel free to add your opinion regarding both approaches.

[dleng · Accepted solution]

I would say put it as a new status? Preferably the transition should be accessible from any of the statuses in your workflow... but this is only if you are allowed to "defer" your issue at any point in time.... Say, an "In-progress" issue can be "deferred" for further action later. Putting it in deferred status also means the issue has not been resolved yet (which is the case anyway). In JIRA, adding a resolution other than "Unresolved" would make JIRA think that its already resolved.

[Nic Brough -Adaptavist-]

I'd go with Daniel and Joe as well.

The problem with having Closed//deferred is that Closed really does tend to mean "dead, we're not going to do anything with this ever again".

In most process flows, you probably want it separate from Closed, simply to say "we're not going to do this yet, but we will go and look at it again later".

[Joe Pitt]

I concur with Daniel. Issues that have a resolution value don't appear in most of the canned reports and are often forgotten about and never actually resolved. In my experience issues are deferred because of a situration or reason that will be resolved at a future date, such as an upgrade to a COTS software product or management decision.

[Andrei [errno]]

older discussion @ https://answers.atlassian.com/questions/55550/deferred-status-resolution-or-version