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
