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

[Agustín Benito Bethencourt <agustin benito codethink co uk>]

Hi,

On Monday, 14 May 2018 11:00:13 CEST Tristan Van Berkom wrote:
> 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).

In my experience, all in one solutions are great for small - medium size 
projects that are very technical focused and does not have complex inter-
dependencies. Bugzilla is obviously more powerful 
as ticketing system that Gitlab.

I do not want to open a debate but, if I can choose, I would select RT 
(Request Tracker) but I am not religious about it. I have already worked with 
most common/popular Open Source ticketing systems. How they are used is as 
important as the tool itself, once a minimum functionality is covered.

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

I have worked towards achieving this goal over and over again during the past 
few years. I have a clear enough picture of the finish line. I am flexible on 
how we get there though since we all need to walk together.

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

Correct.

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

I think we have to options:
* I can keep working on the nosoftware a couple more weeks until the examples 
can provide an even better understanding of the benefits of the proposal when 
it comes to labels and boards. This will allow contributors to understand 
better the proposal.
* You guys trust me on this one and, if there are things that does not satisfy 
you, I would be more than happy to discuss them and improve them right away.

I would go for the second one but I prefer to get a general buy-in for obvious 
reasons.  I take your comments as a go.

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

Benefits:
* Clear visualization of WIP. This is very useful, for instance, when 
planning and prioritizing.
* By moving the tickets on the kanban board, state or severity labels will 
change automatically, which saves time.
* Meetings and reports preparations becomes easier.
* Discussions about dependencies between tickets, MRs, bugs... become simpler.

I agree that those who are not familiar with boards, will need to experience 
it for some time in order to evaluate the impact on your day to day work.

>     My usual approach to a "milestone" is:
>
>       - Create a wiki page entirely outside the issue tracker

A milestone requires a description. Sadly Gitlab does not provide a milestone 
description field. I still think the wiki should hold that description (roadmap 
page).

>       - Ensure there are bugs filed upstream for all work items

I am confident we can cover this request with the current proposal.

>       - With bugzilla, I can create a "flagship" bug for the milestone
>         by simply making all related bugs "block" the "flagship" issue

Bugzilla includes a pre-defined and configurable structure, while Gitlab 
structure is almost flat. Gitlab is poor relating 
elements (issues, MRs, labels, etc). This might be perceived as an advantage 
for simpler projects but a huge disadvantage when more complex workflows are 
required.

We will need to solve your use case through a policy based on the proposed 
elements. I will work on it. If the policy becomes complex, we can create 
additional elements to simplify it.   

>     Lets try out the GitLab vision and see what happens.

Thanks for the support. 

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

All I can say is that, as described in the risks, I have considered your 
concern. It will be up to contributors to decide if changes should be 
introduced because the proposed mitigation actions are not enough.

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

Agree. As I have written before, transparency goes beyond exposure.

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

I am volunteering to dedicate effort to set up everything at first and then to 
help contributors to keep tickets in a good shape. My technical knowledge is 
limited so I will need support in triaging bugs.

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

At the beginning, yes.

But as contributions grow, this approach will not scale, so my goal is to 
promote a culture in which core developers follow the policies, serving as 
example to occasional contributors.

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

As the proposal states, we value contributions over processes. The above falls 
into this principle. So yes, we do not expect occasional contributors to 
follow the policies. I hope though that we do it well enough that they follow 
naturally the example of others, who follow the policies.

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

Great.

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

I understand your concern. I've had this discussion several times before, when 
working with Gitlab and Github.

The problem with resolution labels is that, if they are not mandatory 
(enforced by the tool) before closing an issue, the only way to enforce them 
is through policy, which means that somebody has to spend a significant and 
increasing amount of time to enforce it because  people forget to add the 
label once the ticket has been closed. It end up being too expensive for the 
outcome they get out of that effort.

This is always the case for Gitlab.

This is the kind of thing that requires a disciplined group of developers and 
a real benefit for everybody involved to fly. We are not there. The proposal 
focus on policies that will have an obvious or easy to sell benefit/impact for 
those who need to follow them, not just third parties. 

I would prefer to erase them because sporadic contributors might use them 
which would put us in the worst scenario which is, labels being used only 
partially. We can leave them for now though. I will raise the red flag if this 
partial usage impact us negatively.

I predict a future in which the need for more structure to tackle growth lead 
us to a discussion about moving to a robust ticketing system,  integrated with 
Gitlab.

> 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 ?)(by those who use them the least)
>
> 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 :)

Correct. They are relevant for visualizing the WIP and in the future, for 
forecasting the capacity.

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

Fair enough.

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

I hope my experience on this field will have a positive impact on the project 
sustainability, which has to consider both, effort growth and temporary 
decline. 

Best Regards

-- 
Agustín Benito Bethencourt
Principal Consultant
Codethink Ltd