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

[Laurence Urhegyi <Laurence Urhegyi codethink co uk>]

Hi,

On 21/05/18 10:26, Agustín Benito Bethencourt wrote:
> 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.

Thanks for the clarification to the changed nature of the Critical label, this 
is important to take note of.

> 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.

So, to confirm, there is a minimum of 3 and a maximum of 4 types of labels to 
consider when raising a ticket. Firstly:

* Severity
* Status
* Topic

I think that every ticket should have the above 3 labels applied, is this correct?

Then the fourth category of ticket:

* Impact

Which should only apply to bugs, of course.

Thanks,
Laurence