GNOME.org
 

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

Apologies I haven't got around to responding to this earlier.

Have commented on the MR also:

https://gitlab.com/BuildStream/nosoftware/alignment/merge_requests/7/diffs?commit_id=921b10e1569e45723878ce19e92a34ca91251b76

On 29/10/18 15:05, Tristan Van Berkom via BuildStream-list wrote:

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.
Agree entirely about simplicity. If people feel we are over-using then we should take on-board that feedback and adapt the policy accordingly. We need more contributors to join in this discussion, really.
My goal here is create a policy that is clearly defined and simple for anyone to pick up. Some stuff may not work, and if we realise that over time then we can change it if we agree, but let's get things simplified, agreed and defined. 


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.
But our gitlab was a bit of a mess back then. It could take a long time to find the issue you were looking for, for example. And the amount of contributors has grown massively since (and thus so has the amount of tickets raised) so we needed to mature a bit, I think.
Also, I don't think any of the above was clearly defined. If you worked at Codethink you understood it but outside of that, I don't think it wasn't even written down. So we've certainly improved in that regard. 


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.
I think you may be exaggerating how much those particular emails add, but yes, there are *a lot* of emails if you watch all of the gitlab notifications as we both do, so less of those can only be an improvement. Personally it is fine by me to go to 'only self-assign'. And on that note try to keep gitlab tickets to technically relevant details and minimize the noise, as opposed to comments related to 'status' etc. 


* 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).
You and others have differing opinions on this. I don't feel very strongly either way. This would be solved anyway if we followed the above points. 


* 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.
I hardly think the status labels are adding much of an overhead. It takes 2 seconds to move a ticket from one column to another.
Rather, the inconsistent and confusing way that 'severity / high_impact' is being applied needs addressing, and there are a lot of 'category' labels which don't even get used, as far as I can see. Having so many labels in in a drop down list is a bit over-whelming for a new contributor and will surely only drive them away from bothering with labels. 


   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. 

Agree. Which is why I wrote the patch.


   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


Sounds sensible to me. As long as we clarify and define.



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


Is this really the case? I don't think it is, and I certainly hope not.

<snip>


I'm not going to jump the gun and change any policy at this time,
And nor should you: I don't think anyone has the right to do that. It's a policy that we'll all have to use daily and we should put it forward on this list to agree before settling on something. 

 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.
Yes. For example, I imagine that everyone will agree that the issue and MR templates have been a very good addition.
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]