Issue types: User story, test case, requirement, vulnerability

added Category:Quality Management Category:Requirements Management Plan [DEPRECATED] issues labels

changed the description

What about bug and feature request?

Should we allow to define certain labels as issue category? That would allow flexibility on a group level and we could probably even use some of the existing logic for labels.

I think it depends what that category is and how unique its needs are in terms of use cases. Did you have anything particular in mind?

Did you have anything particular in mind?

This thought was inspired by vulnerability (aka security ), bug, and feature request which we currently use labels for.

@winh: I see us using custom fields for differentiating between bugs vs feature requests (&235). Because the flows are largely the same at least for planning/scheduling/execution. Having a custom field for differentiating will make it easier to do filtering and board/list management. But I don’t see a need for a separate issue type.

For vulnerability and test case (as I linked to in the description), I see there are quite different in use cases, so that’s where I see a need to branch off into different types.

so that’s where I see a need to branch off into different types.

Makes sense to me! 👍 I wanted to suggest that users can customize the name of those types but that violates convention over configuration—so probably a bad idea.

Would it make sense to have one like "Research"? Where we want to research specific avenues but are unsure what the outcome will be. This issue is an example of research in Geo: https://gitlab.com/gitlab-org/gitlab-ee/issues/8729

@markpundsack: At first glance, I wouldn’t think bug vs feature request would warrant different types, since they would both go through the same flow as being worked on by a development team in a typical Agile workflow. If we ever build in specific native functionality for example to track defect rate, that might be a good time to pull out bug as it’s own type though.

@rnienaber: I think “research” would depend on what specific use cases you had in mind and that is different enough to warrant its own type. In your example, I think the existing issue behavior suffices for that purpose right? An issue is opened to discuss and document research. When the research is done, the issue is closed. I don’t see any need for a separate issue type?

@victorwu Thanks - that makes sense. When I re-read the description above, the last line of it makes this clear. My apologies for not letting that settle in my head before commenting.

@rnienaber : No apologies needed. I think the research results could be interesting. Whether it’s UX research or a a technical spike, we don’t currently have a nice place to store that long-term information that’s natural. For example, if you wanted to store the architecture diagrams of your product/application, you can currently put that in a source controlled readme file or a wiki. But both those places don’t have inherent strucuture. Possibly having an issue type that stores this information could be interesting, since you already have labels and issue relations and all the features of issues. This I think would be similar to the requirement issue type, which would store long-lasting business logic. Essentially this could be a lightweight alternative to having full-fledged documentation artifacts.

Thanks @victorwu, I feel we now have the need to implement something in this direction, and I'd love if it could be something generic that will be reused in different contexts.

I think that the main difference to figure out if we want an "issue type" or not is if we can automate a flow based on those custom fields.

For example, vulnerabilities need to have specific params defined, and we cannot rely on labels and description since they are not guaranteed or well defined in the product (even if they can be in the specific flow, but this could be different from customer to customer).

and possibly even remove certain fields if necessary.

I'm not sure if we will need to remove certain fields from the "basic" issue model.

Probably we can just keep them unused by the specific flow, and users will still be able to use them if they want, to make the tool even more flexible. For example, we don't use time tracking (at least, I personally never used it), but it is not a problem to have it and I suppose someone finds it very useful.

What about bug and feature request?

@markpundsack I agree with Victor in https://gitlab.com/gitlab-org/gitlab-ee/issues/8767#note_123343386: if we can automatically create a bug management flow (SLA, etc) then yes, it should be a new issue type. That's the reason that made me thinking about issues with custom fields for vulnerabilities in the first place, we need to establish a flow (vulnerability fixes) that requires specific information.

Pinging also @joshlambert since he is probably also interested in this topic for incident management.

Requirement is a property of an issue I think, not a type. We need better relationships between them.

One benefit of this approach is that it unblocks individual stage areas to innovate independently with new issue types but still leverages the basic existing features of issues as a launching pad of functionality.

So for example, if the Secure folks want to innovate on the Vulnerability type, those issues could appear in certain list/dashboard UIs in their own areas and only appear in the tiers that they are designed for. The Secure product area could create these features on their own with minimal Plan help.

If the default issue type is unchanged, it also doesn’t disrupt any existing features/flows. Issue lists and issue boards need to be carefully considered though. Should they display all issues? Or just the specified type? What should be the default? I think just displaying the default type makes sense to start off and then each individual product area can consider if they want their issue type appearing in issue lists and boards and how.

I think this makes a lot of sense for Incidents as well: &349

As noted in the description, we will need to have type specific UX and logic. Here is a concept design we had from a few months ago:

@victorwu what release do you see adding the core functionality for this, and then enabling other teams to come in an add additional types?

We would like to start shipping the first MVC of Incident Management in probably the 12.0 timeframe.

@joshlambert: Since this is a big change (issue types), I’d like to get the opinions of @smcgivern @andr3 @pedroms @JobV before we charge ahead.

As for actual design and implementation, I expect whichever team needs this first to be able to collaborate with Plan designer (@pedroms) and Plan engineers if Plan doesn’t do it first. 12.0 is coming soon. Plan would maybe need this for requirements management and test management. I’m not sure if Plan would do either of these that soon. So if Monitoring team wants to do this soon, I think we can scope out the issues required and then discuss specifics/impact there.

But let’s get @smcgivern @andr3 @pedroms @JobV to chime in as soon as possible first.

@joshlambert : Chatted with @JobV , and he agrees with the concept of issue types. I'm going to be working on an MVC for test case management (https://gitlab.com/gitlab-org/gitlab-ee/issues/8766), that would incorporate issue types. I think if you could do the same for incident management, then we can compare the issues/designs, find commonalities, and come up with a plan on when we do each.

changed the description

Here's my thinking: issue types make sense if they offer a meaningful benefit. I think incident management issues make a lot of sense, as they'd need specific additional features or fields.

We can introduce types one-by-one, and only do so when they introduce specific, useful additions to what issues do today.

mentioned in epic &617

@joshlambert and others: Here's a sketch of how a Test case could be an issue type, for quality management use cases. &617

mentioned in issue #8799 (closed)

mentioned in epic &634 (closed)

Thanks @victorwu for proposing this.

The idea is that each issue type would extend the basic issue type (user story) with additional fields and logic in GitLab, and possibly even remove certain fields if necessary.

Supposing that custom fields (&235) are planned too, perhaps we should consider this when designing model representation of these types - I wonder if both custom fields and issue types could use same solution.

, and possibly even remove certain fields if necessary.

Removing certain fields might be tricky, if existing Issue can be considered as a shared base model, I think it makes sense to build types on top of it, but if some issue types would be significantly different we should consider if it should be still treated as an Issue or if it should be separate issuable entities - we already have shared logic for all issuable types (Issue, MR, epic, snippet).

I agree with @jprovaznik. If a new type is an issue, plus a different UI, plus some extra optional fields, then it seems like a good fit.

If it needs to remove fields, or add new required fields, or have widely-varying behaviour (different states, for instance), then I think that is a less-good option, because it will add a lot of code complexity.

changed the description

@smcgivern @jprovaznik I’ve removed the point about removing fields in the description since I don’t think it’s important in the use cases.

@victorwu - do we plan on making Issue Types an EE only feature? How would that work with any feature that makes use of Issue Types (aka Incident Management), which we would want some portions to be available in CE?

Maybe built-in Issue Types like Incidents could be CE, and user created Issue Types are CE?

@joshlambert : What do you mean by user-created issue types? My concept here is that any new issue type would be a system-defined native GitLab issue type. As a user you cannot define any new issue types.

And so for each new system-defined native GitLab issue type, it is up to that stage group to decide the tier of it. So for example, perhaps you wanted to launch incident management as a new feature as a Core feature. Then Core users could create incidents and use that feature. And perhaps later you wanted to build additional advanced features on top of that for say Premium, e.g. extra advanced fields on the incident issue type. Then those would be Premium fields.

So from that perspective, we don't really say issue types is an Enterprise feature. It's just a framework where we are extending issue functionality.

So from that perspective, we don't really say issue types is an Enterprise feature. It's just a framework where we are extending issue functionality.

@victorwu can we move this to CE then? If we don't plan to expose this to end users to manage, each issue type should be able to have its own license as needed.

@joshlambert: Thanks for pinging and reminding me. I'm just going to close this issue then. There's nothing actionable here. We've decided that issue types is a good approach and we should proceed with it, at least for incident management and probably vulnerabilities.

It looks like you are starting to design out an MVC for incident management in https://gitlab.com/gitlab-org/gitlab-ce/issues/55526 and https://gitlab.com/gitlab-org/gitlab-ee/issues/8905. That's perfect. I think one of the outputs of that design should be how you incidents interact with regular issues. For example, in the MVC, are incidents manually created, or automatically created? If manually created, is there a new dedicated web form where you create an incident? Or do you add a dropdown in the new issue form to choose incident? Whatever design comes out of there, we can figure out if there are any changes that the Plan group needs to do to support that design and we can schedule those new issues accordingly.

closed

mentioned in issue #9685 (closed)

mentioned in issue #10242 (closed)

added Enterprise Edition label

mentioned in issue #25840 (closed)

mentioned in issue #31605 (closed)

mentioned in issue #339159

changed the description

removed Plan [DEPRECATED] label

Issue types: User story, test case, requirement, vulnerability

Designs

Child items 0

Activity