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

[Laurence Urhegyi <Laurence Urhegyi codethink co uk>]

Hey Tristan,

On 13/11/18 09:02, Tristan Van Berkom via BuildStream-list wrote:
> Thanks for bringing this back to the list, this conversation deserves
> much more attention than dwelling in the above merge request, which I
> would implore others who are interested in this thread to also read.

Thanks for carrying on the discussion with me - I think we are clearly aligned 
in wanting to improve/simplify matters :)

FWIW, I agree with a lot of what's been said, and so have snipped a lot of that 
detail from this response.

> Now that we have several boards to view the issues which people insist
> on using, the rest of us need to see the issues in several different
> views.
<snip>
> There are currently only 277 open issues:
>
>     https://gitlab.com/BuildStream/buildstream/issues
>
> But if I have to see them through several different windows, I feel
> like we are multiplying the cognitive effort of consuming the issues by
> the amount of boards we have. The boards should only be useful to those
> who use them, and using them should not be imposed on the rest of us,
> this only adds confusion to what is otherwise a nicely sortable and
> filterable list of only 277 issues.
>
> But this problem with the boards is the least of our worries, if this
> was the only problem then I don't think we would have reached a point
> where affirmative action is required.

Less boards would certainly make the overall board experience better. I would go 
for 'Severity' and 'Status' if it was up to me.

However, perhaps I am in a minority of people who value the 'Status / WIP 
visibility' view. If so, that's fine, it's something I will live without, since 
there is also an argument to say that the management for teams who are paid, 
full time contributors should be done outside of the upstream bug tracking system.

<snip>> Notification spam
> ~~~~~~~~~~~~~~~~~
<snip>
>      Unfortunately, people file way too many merge requests, and
>      we have tons of them sleeping in WIP needlessly, this we should
>      also put an end to with stronger policy.

Raising WIP MRs is probably a very large aspect contributing to the notification 
spam.

Removing these would be a trade off, of course - in the past people have 
encouraged people to create WIP MRs to show the code that they're working on and 
show progress, and that proved beneficial in some cases.

One thing we could do (related but only tangentially) is go through the MR list 
and close off the stale WIP MRs, after giving people a week's notice. If people 
care that much they can open a no WIP MR later. What do you think?

<snip>
> Solution
> --------
> Revert mostly to what we were doing before.
>
> There are a few major points to change in order to have a simpler
> experience interacting with the issue tracker, and restrict
> notifications to only relevant ones.
>
>    * Revert to the old usage of the asignee field
>
>      Revert back to the assignee field to be used as self-assign only,
>      and as a signal to show that someone is working on patches to solve
>      the issue, so as to avoid any duplication of work.

Sounds good to me.

>    * Back out the WIP related tags and kanban-like boards
>
>      This stuff adds a ton of notifications

Genuine question: what notifications? If we are still talking about email 
notifications - as opposed to the small notes on the webpage UI - then apart 
from the assignee changing I can't think of any.

 that are unrelated to
>      issue tracking and only pertinent to tracking work in progress,
>      while at the same time lowering the bar for anyone who wants to
>      work on BuildStream and interact with the issue tracker.is n
>
>      We can keep the severity board around, for those who prefer
>      to view the issue list as separate columns instead of just
>      using the prioritized labels to view the entire issue list.
>
>      In any case, we need to keep severity labels around, so
>      having it drive a board will not be an obstruction or add
>      any cognitive complexity for those who do not look at boards.

Yes, and to reiterate a previous sensible suggestion, base the label on 
conditions (you mentioned how often it occurs, does it cause data loss, etc).

>    * Implement a policy for not creating merge requests prematurely

Sounds good to me.

<snip>
> If people feel strongly about keeping the priority/severity labels
> around, then I implore you to please reply with concrete advantages and
> examples of how these things are improving our lives, wieghing these
> against the clear disadvantages I have tried to outline in this email.

Perhaps we are getting tangled up in terminology, so to try to clarify:

* You're advocating severity (aka impact) labels, with defined criteria
* These tickets can be filtered and viewed with a board, if desired
* You want to remove any notion of priority (aka important/urgent)

I think we are getting closer to agreement here (I think the others who may care 
about this as much as we do are too busy to get involved in this chat at the 
moment) so thanks again for putting the time in :)

Thanks,
Laurence