We are addressing the ability to change the type of an issue in #268370 (closed). To help prevent the mistake from being made in the first place, users need more context and explanation when creating a record at the beginning.
Provide people with additional guidance about what the different issue types are
Proposal
Introduce supplementary text to explain which issue type should be used when, so people have that information up front, before they make their selection:
Update: Issue explanatory text should be - For general work
An incident is used primarily for time-sensitive work for things like systems outages. Some features available on issues may not be available on incidents.
Minor change suggestion to make it more definite.
An incident is designed and used primarily for time-sensitive work for things like systems outages. As a result, some features for issues are not available on incidents.
Is there an issue for the other way when someone is creating an issue, but they want to create an incident. I've seen various suggestions in GitLab popup when I create issues, I wonder if there's a pattern we can reuse.
@kbychu I like the reword suggestion - I'll get it implemented.
Is there an issue for the other way when someone is creating an issue, but they want to create an incident. I've seen various suggestions in GitLab popup when I create issues, I wonder if there's a pattern we can reuse.
There is not. If we do this I think that we are setting the paradigm that ALL issuable types should have a block of text explaining the purpose of the type. There are going to be many more types. Do you think that we should pursue that course?
For now, this issue is about helping people understand what they are creating when they select Incident since that was the problem that generated the need for this issue.
I have a small change I want to make to the text, if you agree:
An incident is designed and used primarily for time-sensitive work for things like systems outages. As a result, some features for issues are not available on incidents.
@sarahwaldner - @cnorris came up with an idea to solve the problem of people "wrongly" creating incidents that could either be used in addition to or as a replacement for the alert idea we have here currently. Essentially, the proposal would be to have sub-text in the dropdown so people have a better idea of what they are choosing before they select an option in the dropdown. That could look like this:
I suppose we'd have to get Plan's sign off on this proposal but, I think it could be good to introduce supplementary description text in the dropdown here, especially as we start generating more and more issue types. WDYT?
I had another thought on the text (either for this idea or the previous one) - do we want to explicitly state that an Incident doesn't include all the features of an Issue? Because the latter is true too. Issues do not contain all the features of an Incident. And I am sure the same will be true for other types. I think the supporting text should simply be a description of the purpose of that type. Thoughts?
I think this is a good point, @sarahwaldner. That extra detail was added because people were stressing that incidents didn't have milestones. But, now that milestones have been added back in, the only thing that's "missing" from the sidebar is the epic and iteration. And, you're totally right, issues are also "missing" things that incidents have! With that in mind, we could update the text like this, to also include the recommendation that incidents are used for things like systems outages:
WDYT? Also, is it true that incidents should be used for "time-sensitive tasks"? I'm wondering if maybe we should simplify this even further and just say that incidents are to be used "for systems outages," as that's really what we want people to use them for, right? Or is that making the use case too narrow?
In terms of whether we should utilize this new dropdown idea or the alert idea originally suggested in this issue's proposal - @cnorris had the following concern about the alert idea:
As for the warning, I don't think we should advertise a product feature with a warning message. Marking things with warnings may scare off adopters. A concise explanation in the appropriate location is enough, and should include the information about both issues and incidents, to help users make the best choice.
In general I'd say this is true but, the warning seemed alright in this scenario given that we already use a similar warning for the template selection dropdown, so it's not a surprising message to receive on that screen. Also, given the tendency for people to create unnecessary incidents, maybe we actually do want to make them hesitate before using it But, we do already have this message displayed when someone selects the incident issue type:
...And, with the addition of the supporting text in the dropdown, we might not even need the warning anymore. I could probably go either way on the warning message so, would love your thoughts!
WDYT? Also, is it true that incidents should be used for "time-sensitive tasks"? I'm wondering if maybe we should simplify this even further and just say that incidents are to be used "for systems outages," as that's really what we want people to use them for, right? Or is that making the use case too narrow?
I do not think that time sensitive task is specific enough. Unless it is related to an IT service problem (disruption/outage) someone should use something else. I am thinking something along the lines of IT Service disruption or outage. WDYT?
...And, with the addition of the supporting text in the dropdown, we might not even need the warning anymore. I could probably go either way on the warning message so, would love your thoughts!
Yes I agree! Let's remove the warning notice. Especially now that we are going to add the ability to change the type on the issue. They can reverse the action if needed.
Holly suggested having the additional text behind a question mark, so that this dropdown doesn't get crazy cluttered when we have many issue types. If we do something like that instead, it would look like this:
The benefit of this route is that 1) it doesn't change the current workflow at all for people who are just creating issues as normal; 2) it provides extra information about the issue types if it's needed; 3) it will scale well, so that when we introduce new issue types (and when we have lots of them), they can just be added to the list without that dropdown getting really long.
Since this is scheduled for development in 12.9, I've added this new screenshot to the issue description. But, if you have additional thoughts on this, happy to edit further. No one has picked this up yet, so I think we still have a window to adjust, if need be
cc: @jmandell (as I think we're meant to cc you in on all posted designs)
My concern about the hover on the ? is that what happens when there are 10 issue types? 15 issue types? Does that hover become long? wide? It doesn't seem scalable to me.
@sarahwaldner - the popover body could theoretically have a scrollbar, just as the dropdown does, so that's how we could handle an increase in content if need be. Beyond a certain height, a scrollbar would appear in the popover, and the additional content could be accessed that way.
The problem of scaleability is exactly why Holly wasn't sure about the dropdown approach. When we have 10-15 issue types in that issue type selection dropdown, it will be burdensome to even go through that list. So, if we want to have more information about the issue types in context, we'd either have a scrolling dropdown that impacts everyone using the form, or a scrolling popover that impacts comparatively few people. The latter would probably be preferable, in terms of impact.
I also think that, when we get to the point of having 10-15 issue types, the ? popover could probably just contain a summary sentence about what issue types are with a link to the documentation with more details about each. But, building this affordance in now allows us to keep refining the content in future as need be.
@hollyreynolds and @gweaver - wanted to flag something with you both - we've had the suggestion to include supporting text in the issue type dropdown, giving people a bit more up-front information about the issue types before they make their selection. The proposal currently looks like this:
Just wanted to let you know this was being considered so you had space to raise any concerns. If this is something that you feel would be detrimental in any way, just let us know. Thank you! :)
@ameliabauerly Thanks for the ping!:) I think this is a good idea, particularly as we add more in! I do wonder if the area could get a bit cluttered over time. An alternative could be to include a little ? icon to the right of the dropdown or even a link like, "Issue type descriptions" with a simple tooltip outlining each?
I was thinking about that, as well - the likelihood things could get cluttered in future, I mean. I agree with your suggestion! I'll play around with the question mark approach instead. Thanks a bunch, @hollyreynolds!
@ameliabauerly@hollyreynolds custom issue types will support adding a description so this makes a ton of sense so long as we maybe consider a character limit on the description and/or truncating the text in the menu so it isn’t a wall of text.
@tristan.read I see you are assigned to this. Is this in progress? I've added it to the %13.10 plan for clarity sake. We can also kick it out to %13.11