Re: [BuildStream] Gitlab Proposal: new label: 'paper-cuts'

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

On Mon, 2018-08-13 at 18:32 +0100, Laurence Urhegyi via BuildStream-list wrote:
> Hi again and apologies for my late response here.
>
> On 08/08/18 17:46, Agustín Benito Bethencourt wrote:
> > The main problem are not the labels that are not being used. The
> > real problem are the ones that only a subset of people end up using
> > consistently, every time.
> >
> > The boards are only useful if everybody is strict in the usage of
> > labels. Otherwise additional management effort is required. We
> > agreed that my proposal was manageable with our available time
> > because we could afford managing the labels when the engineers
> > don't. With this dynamic, we will not be able to keep the boards
> > healthy. So the WIP visibility will suffer. The whole idea of using
> > the ticketing system in a more intensive way falls apart.
> >
> > So let me be clear about my ground position: I am convinced we have
> > way more than we need, that the current trend is harmful because we
> > are adding hidden costs, and that ignoring them on behalf of
> > convenience is nothing but demonstrating we have learnt very little
> > from previous experiences.  I will stop fighting against this
> > dynamic, so feel free to propose and add all the labels that might
> > be needed.
> >
> > I have set up corporate tools, like ticketing systems, I have been
> > responsible for them, for their costs, for migrating them, for
> > their failures, the complains.... I will do my best to keep the
> > boards healthy. When I cannot, I will say so, I will take a step
> > back and somebody else will have to assume my responsibility. And
> > no, I am not upset nor frustrated. I am simply making clear that I
> > am erasing the line. Being the Grumpy Grandpa is not in my nature.
> >
> > Every measure that, in order to work well, requires a proportional
> > amount of management effort, will fail in any engineering
> > environments.
>
> OK, I see your reasoning and understand :)
>
> I think instead we can just write 'paper cuts' in the description of the gitlab 
> issues and then use the search feature to find those tickets.

Hi Laurence,

I do have strong opinions about the labels we use.

Originally I had set it up so that:

* We have prioritized labels, which use solid dark colors
  * These were used to classify blockers, critical, bug, enhancement

* We have labels which indicate topics that they effect, these use
  pale lighter colors to be able to more easily distinguish them
  from the prioritized labels
  * These classify things like, whether these are documentation
    related, performance related, frontend/UI related, logging
    related, etc.

* At all times, there was no exclusivity of labels, i.e. an issue
  can be a bug, critical and a blocker all at the same time.

The boards have added a lot of stuff and I will need to make a round of
triage, specifically I need to make sure the "High_Impact" label
reflects more clearly that the issue is "Critical" - which is the
original label we used for this purpose.

Regarding the "Critical" label, I think the only point of contention is
that Agustin wants to use that word/color for the board we use for
prioritization of work.

The reason why I insist to have a label other than that for classifying
and sorting issues in the main issue lists; is because I don't think it
is honest to pretend that an issue is not "Critical" just because we
don't have the resources to work on it in the immediate future; there
is a use case for both approaches, though.

E.g., when prioritizing issues on the board with
Important/Urgent/Critical, we can take the severity of the issue as a
decent guideline for inputting tasks into this prioritization machine
(i.e. it makes sense to consider High_Impact issues first).

Regarding "paper-cuts", I am also strongly opposed to using a label to
reflect how the issue was discovered.

The issue is either a valid issue or it is not relevant. If the issue
is a bug, there should be some way to reproduce the issue and consensus
that the use case is indeed desirable to support. I don't think it is
relevant at all to classify the issue as an issue that was discovered
in a "dog fooding" project, or by a developer, or by a user.

Cheers,
    -Tristan