Re: [Add Gitlab features to BuildStream 00/04] proposal to apply Gitlab features to BuildStream

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

Hi Sander,

On Monday, 28 May 2018 14:28:31 CEST Sander Striker wrote:
> Hi Agustin,
>
> I'm late to this proposal as well.  I mostly echo Tristan's concern that we
> don't want to raise the bar to contributions.  As such, I do think you'll
> need to own this and groom this for quite a while.  From what I see from
> the thread, you are up for that.

When structuring a project, introducing processes, there is always a risk of 
overdoing it. I'll just say that I took in consideration Tristan concerns when 
I started working on the proposal, not only afterwards.

> I'll respond to the full proposal here.
>
> *Milestones*
> This seems to make sense.  This project is currently following time based
> releases rather than feature based ones, which means things will shift to a
> next milestone if not complete.
>
> *Labels*
> This area is the one I have the most feedback on.  The terminology of
> Severity and Priority has been a discussion topic from me on multiple
> occasions.  I think we need to be careful to properly keep them apart.  In
> the abstract, a issue which is very severe may not get the highest
> priority.  This might be e.g. because the issue is very hard to reproduce.
> Cooking up an example, suppose we had a bug where bst gets confused about
> the state of workspaces.  And the only way to recover is to close all
> workspaces and start over.  And this happened once, with no reproduction
> recipe.  I would call that very severe, but low/no priority.

I share your experience about that debate.

My intention is to reserve the concept "Priority" for the roadmap only, not 
for engineering tasks, bugs, etc. When dealing with non paid contributors, 
priority might be perceived as "this is what we want you to work on". In my 
experience, this meaning is taken in a different way (less directive) when it 
is related with roadmap than with tasks/bugs. 

Combining severity, impact and status with the roadmap priorities, it should 
be fairly simple to imply a sense of priority in tasks/bugs in the upstream 
project. If this is not enough, we can always create a priority scale.

I am aware this approach is not perfect. I explain later why. I am not 
entirely happy with choosing the word severity. In multicultural environments, 
as many of the you know, the concept of severity might have slightly different 
meanings. This is just an example of why a policy document is needed to 
clarify the scales and values assigned, even in the most obvious cases.

In any case, how we name the scales can be changed since they are only 
described in the policy which is WIP. In the worst scenario, a change in the 
scales might lead to a change in one or more label names. This will lead to 
changes in the boards, but at this point the effort is affordable.

> Let me address the 4 levels that have been defined for Severity.
>
> > No label: unprocessed item, no or low priority.
>
> Unless I am misunderstanding, I think having no distinction between
> unprocessed and processed makes triage more burdensome.  What was decided
> to be no or low priority would keep turning up as unprocessed.  But maybe
> you are covering that with the Todo state?

With ToDo and also...

* A processed issue will have a milestone assigned.
* An unprocessed issue will not have any milestone assigned.

In a more structured environment, the above solution will be supported with 
assigning the ticket in the assignee field, which we have agreed to avoid for 
now.

So processed tickets will show up in those boards that refer to:
* Specific milestones 
* Boards which title make no reference to milestone because they have by 
default the option "Any milestone" activated.
 
while those tickets that are unprocessed will only show in boards 
labeled as "All", which were created including the options "Any milestone" and 
"No milestone", if I recall correctly.

I will add the above explanation to the policy.

> I find it interesting that the first definition talks about priority, not
> severity.

That was my bad. My initial intention was to have the roadmap user stories in 
the same repo than the technical tasks. I changed my mine after evaluating how 
the enhancement tickets are currently being used. I will send a proposal about 
how to manage the roadmap. 

As mentioned before, I would like to reserve the concept of priority to 
roadmap discussions.

> > Important: default severity for processed items that should be
>
> executed/considered.
>
> Do we call the default Important, because if it wasn't important it
> shouldn't be worked on?
>
> > Urgent: to pay attention in the immediate future when possible.
>
> Again, this reads more like priority than severity.
>
> > Critical: topics that require attention immediately when possible. This
>
> label already exists.
>
> Same.
>
> Actual severity seems to be captured by a label not in the proposal,
> High_Impact?


The above is exactly the kind of debate I did not want to get into. I hoped 
that by leaving the definitions open enough, most people would feel 
comfortable. Then, by using them, we could tune the definitions. Here is why...

The issues we are creating in gitlab are, at least of the following kind:
* Defects
* work packages (tasks)
* user stories
* epics (big tasks that can be sliced)
* requests (services, goods...)
* others (combinations of the above, different ones...)

Formally speaking, Each one of the above fall into different categories when 
it comes to classify them, with different scales and values. 

When we are talking about incidents management, priority comes as a 
intersection (matrix) of the concepts Urgency and Impact.

When applied to risk management the impact concept changes and, depending on 
the type of risk management we are talking about (acquisition, operational, 
assessment...) , you will find  different applications and scales for severity 
and impact.

When talking about software quality, it is interesting the concept of defect 
criticality. The class of defect depends (formally) on two scales: Severity/
Impact and Likelihood/Visibility We were using the label Critical in this 
context. I tried to avoid it at first, and introduced the impact scale later.

When talking about user stories, we can classify them by MoSCoW, paired 
comparison, Kano Analysis, a variety of points systems...based on the business 
value which can be directly related with impact, severity or/and priority 
depending on the circumstances and methodology approach.

My point here is that due to the wide variety of types of issues we are 
dealing with, it is arguable which scales to use for what and which values to 
apply. 

I would be more than happy if we can consolidate three scales with 3 to 4 
levels each in a future. Even in such case, the type of issues currently being 
are too wide to find out the right scale to categorize each one of them.

I will try to improve the current situation by:
* Rewriting the description of each severity level, looking for a better 
differentiation of a priority concept.
* I deliverable added the word impact to the only label we have for the Impact 
scale to avoid misunderstanding. I will rewrite the scale definition and label 
description to be more accurate.

In any case, I would like to avoid being strict. In my experience, when scales 
become a topic, it means that the project is demanding a significant increase 
of structure, in which case we are talking about the need for a project 
manager. 

> *Boards*
> I can see those be useful for transparency/visibility.  Is there a way to
> monitor how often these are actually used?

Not that I can think of on Gitlab. I am using them already on every meeting 
for both, preparing it and to follow it up.

@All. I would appreciate if in a few weeks you tell me if you are using them 
and what for.

Once we have a solid roadmap, we can translate user stories into weekly tasks 
which, together with the boards, would provide us forecasting capabilities, 
based on previous records.

So WIP visibility is the first step towards forecasting completion times in 
controlled environments, which Open Source projects are usually not. 

> *Templates*
> I think it makes sense to use templates.  I could not actually visit the
> links to the templates in the proposal (404).  Is it possible to make the
> chosing of a template mandatory?  Without that I don't expect people to
> necessarily click the Choose a template dropdown.  Which is a missed
> opportunity.

Many could not see the examples because I did not add them as Members of the 
nosoftware subgroup on Gitlab. Apologies. I have been adding people to it 
since the proposal was out. I just added you, Sander, to the "communication" 
repo. You were already added to the "alignment" repo.

@All, please let me know if you cannot access to any repo at the nosoftware 
subgroup.

In any case, the templates has been implemented here: https://gitlab.com/
BuildStream/buildstream/tree/master/.gitlab

The task template and the merge request template has been also added as 
defaults.

> Thanks for putting the proposal together, and for volunteering to maintain
> this data.

My pleasure. I am getting good help from Laurence. 

@All Thank you all for dedicating effort to keep the tickets healthy, so using 
the boards is possible (and useful).

I hope the above explanations does not sound too presumptuous but I consider 
myself a veteran in PMO vs engineering/R&D/product battles. I try to avoid 
getting into them unless absolutely required.

Best Regards


-- 
Agustín Benito Bethencourt
Principal Consultant
Codethink Ltd
We respect your privacy.   See https://www.codethink.co.uk/privacy.html