GNOME.org
 

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

Hi,

On Tuesday, 22 May 2018 09:58:25 CEST Laurence Urhegyi wrote:

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?


The three scales should be considered in every case.

The Severity and Status has a first level a "no label" so I do not expect to 
see a label of each scale in every ticket, just for the Topic one. On the 
other two cases, it will depend on the case. Let me put an example to clarify:

* Status: I create a ticket to track a task but I am unsure if it is the right 
tasks or if a colleague of mine would agree. I leave then the status label 
with "no label". It would go into "ToDo" only when the description is 
completed and both of us agree it is something worth doing as described.

* Severity: I just created a ticket  that somebody else needs to work on, not 
just me. The task affects to several areas of the project so it requires a 
conversation with other people too. In such a case, you leave the severity 
label in the lower level ("no label"), until the conversation takes place and 
the severity is widely understood. Then it is assigned to "Important".

In summary, I would expect to have a label per scale for mature/processed 
tickets. 

The approach we are following is less structured than having a specific label 
assigned to the first level of the scale but it gives room to those 
contributors who do not follow the policies initially to learn them as they 
contribute. Once the current policy is widely followed, we can discuss about 
pushing it further, specially if we grow in the number of contributors. 

I am writing down the policy document to clarify the expectations and provide 
advice about this topic: https://gitlab.com/BuildStream/nosoftware/alignment/
blob/master/BuildStream_policies.md


Then the fourth category of ticket:

* Impact

Which should only apply to bugs, of course.


As a general note, I would remark that most of the people currently working on 
BuildStream are full time employees, but not all. We need to move carefully 
when applying measures that increases the effort and knowledge required to 
contribute to the project. They must be absolutely worth it because they might 
be expensive.

Best Regards
-- 
Agustín Benito Bethencourt
Principal Consultant
Codethink Ltd
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]