Re: [BuildStream] Re-structure of BuildStream Gitlab policy document

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

On Fri, 2018-10-26 at 13:01 +0200, Laurence Urhegyi via BuildStream-list wrote:
> Hi,
>
> I'd like to invite you to review the following MR with some updates to the 
> structure BuildStream's Gitlab policy document (not the actual policies 
> themselves):

It's probably a good time to start discussion around our (over)use of
gitlab, indeed I think the bar is too high, and more importantly we
have a terrible signal to noise ratio.

We had a very simple policy before, which I believe allowed for decent
level of notifications and visibility, this was basically:

* There are only two types of label

  * severity (enhancement, bug, critical, blocker), these effect the
    default sorting of the main issue list, via label "prioritization".

  * category (frontend, cache, optimization, logging, etc), these allow
    one to view issues related to a specific area or aspect of the
    codebase.

* If your merge request is not ready for upstream review, prefix it
  with WIP so that we don't have to consider it.

* The assignee field is only there to ensure we avoid duplication of
  work, and we only ever self-assign.


Let's take a step back and see what we really need, and what are the
problems with the current setup:

* Signal to noise ratio is unbearable.

  I get hundreds of emails a day related to issues and merge requests,
  and the majority of these are quite meaningless. The biggest offender
  here I think is over-use of the assignee field, while having too many
  labels still contributes to this.

* Assignee button pushing is not a civilized means of communication.

  People should be capable of forming complete sentences and actually
  engaging in human communication when requesting that someone review
  something, or requesting that someone comment with their opinion on
  something.

  There is no value to the project to know what is assigned to whom
  beyond just knowing who is doing the engineering work to close a
  given issue at a given time (i.e. to avoid duplication of work, we
  want to use the assignee).

* Labels are overly complicated, as you point out.

  This adds burden to anyone filing an issue or later tracking
  progress, not to mention that bookkeeping of too many details
  contributes to the bad quality of our signal to noise ratio.

  I would argue that the new status labels (todo, doing, verify, etc)
  are irrelevant to the tracking of project issues, we can do away with
  all of this complexity.

  It is more important to have a simplified issue filing and tracking
 
experience, optimized for new contributors and drive by contributors,
 
than it is valuable to do this level of book keeping in the issue
 
tracker proper.

  From a highlevel project perspective, we should really only be
  concentrating on the merge request list, and only those merge
  requests which are not marked as WIP. Prioritization of work that is
  in progress, and tracking of that work, should be up to those who are
  doing the work and sometimes managers (in the instances where
  contributors have managers).


Regarding your question about severity / impact labels:

  I personally only care about the truth: if there are 500 open issues,
  and 400 of them are critical, then so be it. There is no point on
  pretending that issues are less severe because we have limited
  resources; prioritization of work on more severe issues can just as
  well be done outside of the issue tracker.

  The story behind the "High_Impact" label is basically that it should
  be the "Critical" label, except that there is a desire to keep the
  number of critical issues in the "severity board" to a minimal
  number, I cannot really explain or understand the rationale behind
  this.

  For this case I would suggest that we base the critical label on
  actual conditions like:

     - Does it cause someone to lose data
     - Does it happen often
     - Does it result in an irrecoverable project state or corruption
       of the local artifact cache
     - Does it result in a stack trace without a decent explanation of
       what went wrong to the user, or explanation of how the user
       can recover

  And then we can just remove the High_Impact label completely, since
  the intention of the High_Impact was to be the "Real Critical" label
  (as opposed to the "What we pretend is really critical based on what
  we have time to focus on").

  I had previously spent a lot of effort in classifying issues as
  Critical or not, but with all of the new overhead I have not had the
  time to recover that information in the High_Impact label, so the
  High_Impact label currently doesnt reflect what it should.


I'm not going to jump the gun and change any policy at this time, and
would love to hear from the wider community about which enhancements
that have been added to GitLab are useful to us, and which of these
enhancements have only resulted in workload overhead and notification
spam, so we can come to a conclusion together and have a better gitlab
experience.

Cheers,
    -Tristan


> https://gitlab.com/BuildStream/nosoftware/alignment/merge_requests/7/commits
>
> ### Description
>
> I've heard complaints recently that people did not know how to follow the 
> policies of the project related to Gitlab. People found the policies to be 
> difficult to consume, so this MR is an attempt to simplify them and make them 
> more accessible.
>
> ### Proposed changes
>
> Changes proposed in this merge request:
>
> * Updates old HACKING links to CONTRIBUTING
> * Cleans up all of the links to be neat hyperlinks in markdown format , instead 
> of full links
> * Massively reduces amount of text relating to templates and also opening / 
> closing tickets
> * Removes information about nosoftware labels
>
> Note: I have left in there what I believe to be some outdated info on the 
> severity labels and impact labels since Tristan changed them. However I'm not 
> too sure how there are actually being used at the moment, so would appreciate 
> some input there. The new world order for severity labels really does not make 
> sense to me....perhaps we can consider changing it back...but that's a 
> discussion for elsewhere....
>
> Also, I think we may need to outline better how to flag a bug you are raising as 
> 'high priority' so that the development team take a look at it.
>
> Admittedly, some of the finer details have been removed. But I believe it is 
> worth it in order to have a more accessible and easy to digest policy.
>
> Thanks,
> Laurence
>
> _______________________________________________
> BuildStream-list mailing list
> BuildStream-list gnome org
> https://mail.gnome.org/mailman/listinfo/buildstream-list