How do I simulate "Wish List" and "Bug List" in JIRA workflow?

[Valery]

How do I simulate "Wish List" and "Bug List" in JIRA workflow?

Should they be states, or resolutions?

[Nic Brough -Adaptavist-]

These sound like different issue types to me.

Representing them in the workflow feels like nonsense - what would be the point of having an item that has status like "bug", "nice to have" and being able to swap between them as part of the workflow?

Having different fields and workflows for the different issue types really does work well though, and setting up something where customers/end-users raise "issues" in one project (without firmly pre-judging what they are because customers often don't know whether it's a bug, a new feature or something else) and having a process where your developers/product-teams triage them over into another project (changing the issue type to the right one on the way)

[Thomas Schlegel]

In my opinion, these should be different issue types. Errors and Features.

[Karie Kelly]

We create different issue types for these and each type has their workflow.

[Justin Corcoran]

In our company, these are treated as different projects, as they follow very different timelines. Bugs need to be fixed before the product goes live (at least the critical ones) whereas "enhancements" need to be sized and slated for upcoming releases.

[Valery]

"Wish List" and "Bug List" issues start as regular bugs (or features). They end up on the bug list/wish list after being resolved as Won't Fix. For example this bug will not be fixed in the next release. We don't know in which release in will be fixed.

[Karie Kelly]

We also triage. But, then just move the issue to the appropriate issue type and/or project to put into the correct queue and workflow.

[Karie Kelly]

We have a transition and state that is Backlogged or you can use something like Scheduled if you are going to work on it right away. Basically, we will move these enhancement or bug requests to a backlogged state and unresolved and then once they are pulled into a version for a release, then they are moved in to a started or in progress state. We have some other states while in backlog such as ready for grooming (all requirements and criteria defined) and groomed (means it has been story pointed or estimated and ready to pull into a version/sprint).

We never resolve them unless they are done, we never plan to fix, or they are a duplicate.

[Justin Corcoran]

Then I would agree with the pervailing wisdom that issue types makes the most sense. For us, we typically "triage" issues before entering them, so we know up front whether they're bugs or "wish list" items.

[Thomas Schlegel]

@ isobretatel: do you think resolving them as "Won't fix" is the right way ? In our Jira, "Won't fix" means, that the issue will never be fixed, not in the next release and not in any future releases.

If we don't know, when an issue will be fixed, we do not resolve it.

[Nic Brough -Adaptavist-]

It does sound like your resolutions aren't being used in a good way. If something is resolved-won't-fix, that really should mean "we are not going to work on this again, there's nothing we can/will do". If it's really going to get looked at for a later release, I don't think it should be resolved at all.