Label "Behaviors"
This is a (possibly crazy) idea that I'd like to float out there. I'm interested in starting a discussion on it to see if it goes anywhere. The concept is to have some pre-determined "behaviors" which can be attached to labels.
The idea was sparked when documenting our internal use of the "Discussion" label in Merge Requests to indicate the difference between "This review is WIP because I'm adding notes to it and preparing it" and "This review is in WIP because I'm looking for some general feedback". My thought was, "what if the discussion tag blocked the review from merging?". This was a stupid thought because that's what WIP already does. But I still think there is some potential there...
Blocking Merges
There have been a few conversations around actively blocking merges (gitlab-org/gitlab-ee#761, gitlab-org/gitlab-ee#876, gitlab-org/gitlab-ee#1979, gitlab-org/gitlab-ee#258). The closest thing we've got is the option to block merges if there are unresolved discussions. It solves the core problem but is not great when it comes to viewing why the merge is blocked from a high-level view.
Attaching a blocks merge
action to a label would allow it to be used for this purpose. Different labels could be used for to indicate different reasons. For example Security Flaw
, No Tests
, etc. The reason would become very obvious because it is in a label.
Prevent logically contradicting labels
Some labels don't make sense when they co-exist. There are probably several in any given GitLab instance, but an obvious one is Doing
and To Do
. If one of the behaviors was Cannot be combined with label(s)
the contradictions could be prevented.
A type of permission system for labels
Can be attached to issue by: ...
, Can be removed from issue by: master, person who added it, ...
A parallel pair focus on use with MRs could play an interesting role when combined with the Blocks Merge
behavior.