Re: [Add Gitlab features to BuildStream 00/04] proposal to apply Gitlab features to BuildStream

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

Hi Agustín,

On Sun, 2018-05-13 at 23:43 +0200, Agustín Benito Bethencourt wrote:
> Hi,
>
> you can find the full proposal on gitlab[1]
>
> This proposal has the following objectives:
>
>  * Prepare the project to sustain the current increase rate of contributors.
>
>  * Improve "work in progress" (WIP) visibility as initial step towards 
> acquiring progress forecast capabilities. 
>
>  * Take a further step towards release enhanced and participate road-maps. 
>
>  * Keep entropy under control while keeping processes simple and lightweight 
> so limited maintenance/management effort is required.

So first, here is my global take on this; I will reply to some of the
finer points inline below.

I will first admit that I am biased against GitLab's issue tracker, in
spite of it's modern UI and colors and features, it cannot beat the
simplicity and "plainness" of bugzilla - this is however not under
debate, we are "staying with GitLab" for all intents and purposes
(unless of course for some reason in the future the situation becomes
untenable, but I doubt that will happen).

That said, here is my overall take on it:

  o You have a vision of how we can better visualize progress and
    ongoing work in the BuildStream project, using features available
    in GitLab.

  o You are volunteering to make a contribution to the project by
    setting up these features and metadata.

  o Some of the advantages you propose are clear (e.g. milestones
    and issue templates), while others I think we cannot really know
    what we are getting until you set these things up.

    Yes, I've seen the example of the issue boards, but I cannot
    imagine how this is going to benefit me, until I experience it
    for myself - I've never used a "kanban" or such and I don't know
    what the value of that is - although I presume there *must* be
    some kind of value in these boards, otherwise people wouldn't want
    them - so I have to assume that this will somehow make life better.

    My usual approach to a "milestone" is:

      - Create a wiki page entirely outside the issue tracker
      - Ensure there are bugs filed upstream for all work items
      - With bugzilla, I can create a "flagship" bug for the milestone
        by simply making all related bugs "block" the "flagship" issue

    Lets try out the GitLab vision and see what happens.

  o I am concerned that the process of contributing to BuildStream
    starts to seem too onerous and bureaucratic, however I presume that
    these features are *supposed* to do the opposite of that.

    We are talking about better visualization and transparency, that
    should remain the goal.

  o Currently we don't have people assigned specifically to do
    "triage", which is an important part of a software project, which
    applies equally to FOSS projects.

    I read your proposal as: You are volunteering to do the bug triage
    work, and you have a vision of how it should be done.

    This means basically that, all of the extra metadata and stuff that
    will be attached to issues, and views and suchlike, will become
    your maintenance responsibility.

    Core developers will try to assign the right label to things,
    because we will eventually get the hang of this, but we will never
    expect an issue submitter or new contributor to have to understand
    all of this: You will correct the labels and such metadata for all
    incoming reports such that these boards and such remain coherent.


Given that you are volunteering to put in the effort to setup all of
this metadata, and later do issue triage and maintenance, I will not
oppose any of this: Things can certainly be a bit better, and we need a
triage person anyway.

[...]
> The proposal is to make (better) use of the following items on Gitlab:
>
>  * Milestones: check mail [Add Gitlab features to BuildStream 01/04] 

Here I can see that GitLab offers some feature to do this, sounds cool,
let's try it instead of using wiki pages.


>  * Labels: check mail [Add Gitlab features to BuildStream 02/04] 

I've read the email, and don't have much objections, note that I have
been using "Needinfo" but I don't mind throwing it away.

The labels:

   o Wontfix
   o Needinfo
   o Invalid
   o Fixed

Are basically what I setup for "Issue resolution labels", a concept
from bugzilla that I don't like throwing away, and tried to forcefeed
into GitLab, but I admit it's not working out - GitLab just lacks issue
resolution labels.

Asides from this, I can see three types of label we might be interested
in:

  o Severity (how bad is this problem, how important is it to peoples
    workflow to have this enhancement)

  o Topic (is this related to the UI ? is this related to a plugin ?
    is this related to logging ? is this related to documentation ?)

  o Progress (is someone working on this ?)

I don't really see a need for labels of the "Progress" variety, but it
seems to be a necessary classification for "Boards" - so lets try it :)

>  * Boards: check mail [Add Gitlab features to BuildStream 03/04] 

I'll have to see this in action for a couple of months in order to have
any idea of how this benefits us.

>  * Templates: check mail [Add Gitlab features to BuildStream 04/04] 

This is certainly a cool feature that we should already be using,
regardless of the rest of your proposal.

At least when someone files a new issue, they should have a template
telling them:

   # What did you try to do ?

   # What did you expect to happen ?

   # What happened ?

This will certainly help us to collect better formulated issues.


So overall from me, let's try this out, we don't have anything to lose.

If and when the extra bells and whistles turn out to cost too much
effort (this will probably happen once we reach maintenance mode), then
we can tear down anything that gets in our way and "just have an issue
list" again.

The more elaborate tracking should help us while there is a lot of
active development, but it should not get in the way when this becomes
a project that a single maintainer can potentially take care of with a
few days of effort per month.

Cheers,
    -Tristan