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

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

Hi,

On Sunday, 13 May 2018 23:50:42 CEST Agustín Benito Bethencourt wrote:
> 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

Once the proposal has been implemented, we have come to the following 
discrepancy:

When looking at the Bugs - Severity board... 

Link: https://gitlab.com/BuildStream/buildstream/boards/580462?
=&label_name[]=Bug

you can see that most bugs does not have any severity label or are labeled as 
Critical. 

The new policy provide a different meaning to Critical since now it is focused 
on the severity for developers while 

In terms of severity, the goal of the label Critical now is that the ticket/
bug is something all developers should be paying attention to, modifying their 
current agendas. Before the concept was more focused on the impact on users of 
the bug/task. 

The current proposal do not provide any accommodation  to that previous 
meaning, which seems relevant to keep, based on the discussions I've had with 
Tristan once the proposal has been implemented. 

So I propose to create a new scale called Impact. This is a scale that mix 
impact and frequency of a bug as starting point. In the future, if there is 
need, we can decouple these two concepts.

For simplicity, this scale has two levels:
* High: the crash is frequent and has a significant impact on the users 
everyday work.  Label: high_impact
* Low: the crash is infrequent or hard to reproduce and the impact on the 
users is low or hard to determine. Label: no label.

It will be restricted for now to buildstream project/repo.

We can make the above more complex as we go if it is proven that it provides a 
benefit at an affordable cost, renaming the proposed new label, adding new ones 
and turning this scale into a global one, like Severity and Status scales are 
today.

Best Regards
-- 
Agustín Benito Bethencourt
Principal Consultant
Codethink Ltd