GNOME.org
 

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

Hi Laurence,

On Wed, 2018-11-14 at 16:38 +0000, Laurence Urhegyi via BuildStream-list wrote:

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.


Right, the board I would like to kill is the Status board, rather; I
don't care about the status board existing, but the fact that the
labels which drive it exist and get updated, is a big contributor to
the notification noise, and overall complexity of the issue tracker.

I'll continue with this point at the end because you touch on this
subject in a few places in your email...


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


There is no reason one cannot share work with their peers before
creating merge requests.

Besides the obvious ways of doing this with the command line, gitlab
even provides some cute features for this, e.g., visit:

    https://gitlab.com/BuildStream/buildstream/compare

This lets you produce a cute UI diff for any source and target branch,
taking the latest MR in the merge requests page as an example, the
above UI lets you view how that branch differs from master:

    https://gitlab.com/BuildStream/buildstream/compare/master...raoul%2F627-RE-instance-config



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?


That sounds like a kind way to effect a transition to a new policy.


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


Yes, we are talking about email notifications.

To my mind, there is only 3 states that we really need:

  * Nobody is working on it (the issue is unassigned)

  * Someone is working on it (the issue is assigned)

  * The issue is fixed / implemented (the issue is closed)

Currently, the 'Todo / Doing / ... / Verify / Etc' status labels add
some finer grained tracking of the status of an issue, and boards are
driven by labels so if you want a status board, you need to use these
additional labels.

When you drag and drop something in a status board, this modifies the
labels, and as a result: everyone gets at least one email.

When you self-assign the issue, everyone gets an email, when you close
an issue, everyone gets an email.

Since we *have* to close issues anyway, and we *want* to use the
assignee field to indicate that someone is already working on
something, these extra label changes are doubling (if not more) the
amount of notifications related to an issue, notifications which
everyone (or at least everyone who works on BuildStream full time and
consider themselves core developers) should really be interested in
receiving.

Of course there is also the flip side which is managing this
information, i.e. we are making it twice as complex to interact with
the issue tracking by adding this labeling overhead related to the
Status board - when all we really need is to self assign issues we work
on, and ensure they get closed when the issues are resolved.

To clarify, I would not mind the existence of this Status board so long
as it does not impose any overhead to the global notifications, and
there is no nitpicking on developers to update these extra labels.

Also, the reason why I mention that it would be fine to keep the
severity board around, is because the severity board is driven by the
prioritized labels which are really needed anyway.

In other words, we need to mark things as Critical and Blocker anyway,
which generates notifications anyway, and the severity board is just a
different view for people who like to see columns.


  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:


I noticed after sending this email that I mixed this part up at the end
indeed, sorry.

What I meant to say is

    "If people feel strongly about keeping the status labels..."

Also I don't think we have "priority" labels, we only have severity, in
any case we should only have severity and nothing else.


* You're advocating severity (aka impact) labels, with defined criteria


Right, we already had prioritized labels, we need them, and having a
board to view them does not add any overhead of metadata or
notifications, as it is driven by metadata (labels) which needs to
exist anyway.


* These tickets can be filtered and viewed with a board, if desired


Yes.


* You want to remove any notion of priority (aka important/urgent)


First and foremost, I want to remove any notion of status (aka
todo/doing/etc).

I would also want to remove the notion of priority, frankly any
contributing party is allowed to prioritize what work they want to do,
and these contributing parties will necessarily have different
priorities, upstream is not in a position to dictate priorities to
contributors.

Priority wise, the only things we can dictate to contributors are:

  * You brake it you fix it

    If your landed branch causes some kind of regression or needs some
    obvious refactor, then fixing this should take priority over any
    feature you are working on.

  * Landing time

    From an upstream perspective, we can prevent branches that are too
    complex and risky from landing too late in the cycle (i.e. early in
    the cycle is the right time to land more risky / big changes).

When a group of core developers sit down and agree on a list of
features we want to land in the next milestone/release, we just have to
trust eachother anyway, regardless of whether we are bookkeeping labels
or not.

That said, I feel that I don't even know the distinction between
priority and severity in our issue tracking, I am seeing boards with
important, urgent, critical and blocker; all in the same scale, and I
think critical and blocker are severities; not priorities.

I think it would be fine to keep "important" and "urgent" around in the
prioritized labels, to have a finer grained severity scale, and just
accept that the concept of priority is not one that upstream can
control or manage.


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 :)


I hope we are yes, and thank you for putting in the time Laurence !

I would really like to start recommending that people include
themselves in the feedback loop soon, and this cleanup is the first
step to having a reasonable notification queue for developers.

Cheers,
    -Tristan
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]