How to change a bug to a task

[Doug]

I have some bugs set up that should be classified as Stories or Tasks. Can you please let me know how to make that change?

thanks

[Nic Brough -Adaptavist- · Accepted solution]

On the actions menu, use "move issue", unless you have the option to directly click on the issue type "field" and change it on view.

[Doug]

Thanks, Nic. Don't think I'd have sorted that out without your help. I'm surprised what a tedious process that is for such a small tweak. 

[Nic Brough -Adaptavist-]

It's not a "small tweak" in the back end.  The issue type is structural, a lot of configuration is hung off it - it determines the workflow and fields for each issue (with the project covering the rest of the config), so Jira has to check that any change of issue type is not going to mangle the data.

[Doug]

Interesting, and I don't doubt that. I was just referring to the user experience, which seems overly complicated. I've read it multiple times and still don't really understand what that first screen with the 'Next' button is saying exactly, other than I'm going to change all Tasks with a check, and even though I selected that option, it didn't change them all. I still had to do each individually. And then there are Confirmation, and Acknowledge screens. 

Seriously, first time through I thought it was some sort of ux test/prank. 

[Nic Brough -Adaptavist-]

Imagine your issue is a castle, or a factory or an airport.  Changing the issue type is akin to saying "I want to convert this building to another purpose, so we're going to need to dig up all the foundations and put down new ones to suit it".  The foundations are the issue-type.

The user experience is about as simple as it can get, although it also is very cautious (lots of confirm/acknowledge) because the changes could be quite drastic and people don't get that.

Remember that changing issue type is something that is an exception.  It's mostly for "housekeeping", and when it's not, then it almost certainly is for "reporter picked the wrong thing" for a single issue.  If it's part of a process, your process is either broken, or implemented badly in Jira.

[ruslan.stelmachenko]

It's still not very user-friendly UX to click on "Move" action to change the type of an issue. I don't want to move it. I want to change it's type.

I really carefully read each option in the three-dot-menu and didn't found anything that could even roughly related to change the type of an issue. Then I googled and found this page.

"Move page" itself also could be improved. The "Step 2 is not required" screen is totally worthless. There is 3rd "Confirm" screen anyway. So why I need to click "Next", then see totally useless screen, click "Next" again and only then "Confirm"? All additional information, that is shown on the 2nd screen could be shown on the "Confirm" screen instead. Maybe it looks like not important, but Jira cloud works not very fast, so additional screen does really matter for me.

[Nic Brough -Adaptavist-]

Digging up the foundations and fundamental structure of an object is not a trivial action.   You're not changing a minor attribute, you're re-engineering something.  It's not "repaint my house", it's "potentially rebuilding the entire thing from scratch"

I don't want to repeat what I said before, could you have a quick re-read of the previous comment?

(I do agree with you on the "step not required", of course, but that has been removed in a couple of places)

[ruslan.stelmachenko]

I totally understand what you said about the fact that changing the type of an issue, while it looks like a trivial action, could be very complex process under the hood. I'm a developer after all, so I know what are you talking about. :)

But, I disagree on the fact that it must be inevitably reflected in the UI. Sometimes - yes. But sometimes very complex operations could be accessible under simple and understandable UI.

We are talking about UX, not the internal implementation on the backend.

Hiding "change type" operation under "Move" menu item isn't user friendly. It forced me to search how to change the issue type in the google. More friendly will be to add duplicated menu item "Change issue type" to the context menu of the issue (3 dots) or maybe to rename "Move" to "Move or change the type".

Maybe there is better solution. I'm not UX expert. This is just my feedback as a user - it's very difficult to guess that to change the issue type I must select "Move" action in the 3-dot-menu.

[Nic Brough -Adaptavist-]

I totally agree with you on that, it's completely obscure that "change issue type is structural, so you have to move".  I don't see it as obscure, but <mumble> years, very little is obscure to me.  But I can still see it's obscure to people with <mumble - x> years.

My (like you say, I'm not a UX person, probably way behind you) solution would be to add a false entry to the drop-down that somehow says "if you don't see the option you want above, we need to talk, click me and I'll walk you through it"

[David Booth]

@ruslan.stelmachenkoyou are 100% correct.  This is a UX design flaw.  It should not be this counter intuitive or difficult to the USER, even if it requires lots of structural change under the hood. 

@Nic Brough -Adaptavist-you seem to be too biased by your long experience with the implementation to see this from the user perspective.  1. When the bug/issue is first CREATED, the user selects the type.  That implicitly tells the user that there is a type associated with it.  2. If you compare a screenshot of entering a bug versus a screenshot of entering a task, the basic information collected is nearly identical from the user perspective.

Conclusion: From the USER perspective, it should be EASY to change the type from a bug to a task or vice versa.

[David Booth]

P.S. I just discovered that it is now easy to make such a change.  Just click on the icon for the type (little red box for a bug; little blue box for a task).  An dialog will pop up, allowing you to change it.   Thanks!

[Nic Brough -Adaptavist-]

It's not a design flaw, it's the right way to do it. 

This isn't coming from "a long experience with the implementation", it's coming from "a long experience in support and development, using issue trackers to capture and help deliver things people need".

If your users are not able to select the right issue type up-front, then your process of getting them to raise issues is broken.  That's often done by having way too many issue types on offer to them, with little clarity on which is which.  

When people complain about not being able to change issue types easily in Jira, it's pointless looking at why Jira appears to make it hard, you should be asking why you think you want to.  That will almost inevitably come back to a poorly built process that demands the users know what types they should be raising.

[Nic Brough -Adaptavist-]

Oh, and on the PS - that will only work when the configuration for the two issue types is identical.  Which is fine for a short list of issue types, but begs the question of why you have many different issue types that all work the same way in larger lists.