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



In short: I trust that you have a vision of how this should work, and think it will be helpful.

In any case if we identify negative impacts, i know you will be around to fix them as we move forward, so i 
favor that you go ahead and start with this right away instead of only demoing in the 'nosoftware' group for 
longer. I wont get a feel for how this works until i actually use it.

Secondary to this, I'll just note that I consider the WIP tracking / kanban-like parts of this to be 
experimental. My intuition tells me that while this is appropriate in a controlled environment, it runs 
counter to FOSS development - from my standpoint i have to treat all contributors equally as individuals, I 
cannot afford to have an expectation of "when something will be ready", its either ready before the cutoff 
(e.g. feature freeze), or it is punted to the next - if something is critical to complete before a release 
and an individual contributor cannot deliver in time, a core developer might at times "steal" the task, but i 
try to minimize this kind of activity as much as possible.

I usually expect that all individuals contribute on a free time / volunteer basis, and this way I am 
pleasantly surprised when we have people working full time and being more productive.

That said, lets try this out and see what happens, possibly this progress tracking can compliment open FOSS 
development and I think you have a vision of how this can work well :)

Cheers,
    -Tristan

On May 17, 2018, at 12:15 AM, Agustín Benito Bethencourt <agustin benito codethink co uk> wrote:

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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]