Valid labeling functionality (label pipelines/workflows)

Problem

Currently you can assign any tag to any issue or merge request. However some labels do not make sense together on a single item.

@markglenfletcher please say if i am wrong here: An issue with both UX and Accepting Merge Requests does not make sense as the issue is clearly not yet ready for any serious public contribution.

In that same way.. it would be nice perhaps to only be able to have an issue tagged with either UX or ~Frontend or backend . So it functions as a sort of pipeline/workflow. Its not UX ? => promote this label to ~Frontend . Its not ~Frontend ? => promote this label to backend (or the other way around for that matter).

Proposal

• Multi Binary labelling system which lets users not assign certain labels if another certain label is still present.
• Promote/switch certain labels with their interconnected counter parts/follow up labels.

Value

• A more automatic labelling linting system.
• Make it less possible to incorrectly label items.

cc: @markglenfletcher @markpundsack @JobV @victorwu @tauriedavis @cperessini @jschatz1

@dimitrieh : Good ideas here, but we aren't at that point in GitLab where we want this level of detail and restriction in our functionality. What you proposed creates a lot of complexity (which is powerful, don't get me wrong), but will significantly slow us down as well develop new features around labeling.

The problems you described are definitely valid, and issue boards are exactly the way we want to solve them. In fact, any type of problem that involves an issue flowing through multiple stages, we want to keep hammering away at issue boards to solve those problems.

mentioned in merge request gitlab-com/www-gitlab-com!5245 (merged)

perhaps we could distill this issue down to:

"Make it impossible to have certain issue be applied both to issues. "

Which would mean, that if an issue is labeled with UX , it would be impossible (would give an error) to label that same issue with Accepting Merge Requests cc: @markglenfletcher

This sounds like a GitLab specific problem rather than a feature problem. Only people within GitLab can add labels so we can document that Accepting Merge Requests should not be added when the issue needs UX work. cc @markglenfletcher @axil Do we have anything in docs about this label? I looked but couldn't find it.

As for you second example, there are many times when frontend and backend are working together. As well as UX and frontend, etc. I don't think we should be limiting the use of labels in this way.

@victorwu has a good point about the use of issue boards to represent issues flowing through multiple stages.

It is detailed here

Do we have anything in docs about this label? I looked but couldn't find it.

Yeah, we have scattered documentation https://gitlab.com/gitlab-org/gitlab-ce/issues/25097 :)

Thanks @markglenfletcher and @axil!

Since this is already documented, I'm not sure there is more action for this issue. I'm going to close. Let me know if you disagree.

closed