[Add Gitlab features to BuildStream 02/04]: Labels

[Agustín Benito Bethencourt <agustin benito codethink co uk>]

Hi,

### Labels

Labels allow us to structure, filter and visualise some of the Gitlab elements 
in different ways. The create an impact in other elements and they introduce 
complexity and effort as they grow in number and usage. So the general 
approach is to have the minimum possible.

Check the description of labels on Gitlab: https://docs.gitlab.com/ee/user/
project/labels.html

Proposal: create 4 different group of labels and deprecate some of the 
existing ones:

 * Severity: 4 levels
        * No label: unprocessed item, no or low priority.
        * Important: default severity for processed items that should be executed/
considered.
        * Urgent: to pay attention in the immediate future when possible.
        * Critical: topics that require attention immediately when possible. This 
label already exists.

 * State: 5 states proposed although two of  them are default states on 
gitlab.
        * Backlog: default state on Gitlab so no label needed.
        * Todo: processed elements that should be done in the future.
        * Doing: WIP
        * Review: items that are under review. 
        * Closed: items that has been processed and canceled, finished or no longer 
apply. Default state on Gitlab so no label needed.

 * Topic/nature: the proposal do not add nor changes the meaning of any label. 
They are currently being used.  
        * Needs Backport
        * Regression
        * Bug
        * Enhancement
        * Documentation
        * Refactoring
        * Reproducibility
        * Tests
        * Logging
        * Frontend
        * Infrastructure

 * Special labels:
        * Blocker: as today, this label is meaningful for releases. It becomes the 
higher level of severity but has implications that the proposed severity 
labels do not have.

 * Labels to deprecate. It is pointed how to handle these cases without 
labels, which reduces complexity:
        * Invalid: not being used. Could be stated as a comment and close the 
issue.
        * Fixed: not being used. Could be stated as a comment and close the issue.
        * Wontfix: not being used. Could be stated as a comment and close the 
issue.
        * Minor: not being used. Severity. Already considered with no label.
        * Needinfo: not being used. Reassignment back to the item creator instead 
of a label.
        * Needs Backport: used only once. Comment + reassignment back to creator.

Severity and State labels would be promoted as Group level labels so they 
would be shared across every Project, including those in nosoftware Subgroup 
(for non-technical tasks). 

Check the examples of nosoftware:

 * Severity and State labels shared across all projects included in 
nosoftware: https://gitlab.com/groups/BuildStream/nosoftware/-/labels

 * Labels assigned to the communication project, where the Severity and State 
labels are inherited: https://gitlab.com/BuildStream/nosoftware/communication/
labels

 * Labels assigned to the alignment project, where the Severity and State 
labels are inherited: https://gitlab.com/BuildStream/nosoftware/alignment/
labels

Best Regards

please remember you can find the complete proposal on Gitlab: 


-- 
Agustín Benito Bethencourt
Principal Consultant
Codethink Ltd