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

[Sander Striker <s striker striker nl>]

Hi Agustin,

I'm late to this proposal as well.  I mostly echo Tristan's concern that we don't want to raise the bar to contributions.  As such, I do think you'll need to own this and groom this for quite a while.  From what I see from the thread, you are up for that.

I'll respond to the full proposal here.

Milestones

This seems to make sense.  This project is currently following time based releases rather than feature based ones, which means things will shift to a next milestone if not complete.

Labels

This area is the one I have the most feedback on.  The terminology of Severity and Priority has been a discussion topic from me on multiple occasions.  I think we need to be careful to properly keep them apart.  In the abstract, a issue which is very severe may not get the highest priority.  This might be e.g. because the issue is very hard to reproduce.  Cooking up an example, suppose we had a bug where bst gets confused about the state of workspaces.  And the only way to recover is to close all workspaces and start over.  And this happened once, with no reproduction recipe.  I would call that very severe, but low/no priority.

Let me address the 4 levels that have been defined for Severity.

> No label: unprocessed item, no or low priority.

Unless I am misunderstanding, I think having no distinction between unprocessed and processed makes triage more burdensome.  What was decided to be no or low priority would keep turning up as unprocessed.  But maybe you are covering that with the Todo state?

I find it interesting that the first definition talks about priority, not severity.

> Important: default severity for processed items that should be executed/considered.

Do we call the default Important, because if it wasn't important it shouldn't be worked on?  

> Urgent: to pay attention in the immediate future when possible.

Again, this reads more like priority than severity.

> Critical: topics that require attention immediately when possible. This label already exists.

Same.

Actual severity seems to be captured by a label not in the proposal, High_Impact?

Boards

I can see those be useful for transparency/visibility.  Is there a way to monitor how often these are actually used?

Templates

I think it makes sense to use templates.  I could not actually visit the links to the templates in the proposal (404).  Is it possible to make the chosing of a template mandatory?  Without that I don't expect people to necessarily click the Choose a template dropdown.  Which is a missed opportunity.

Thanks for putting the proposal together, and for volunteering to maintain this data.

Cheers,

Sander

On Sun, May 13, 2018 at 11:45 PM Agustín Benito Bethencourt <agustin benito codethink co uk> 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.

 ## Rationale

The number of developers involved in BuildStream is increasing so the amount
work in progress. The number and complexity of dependencies among people and
tasks is increasing too, as well as the tool itself. The idea behind this
proposal is to tackle some of the risks associated with current growth. This
proposal take advantage of some of the simplest Gitlab capabilities to improve
the visibility of the different activities that today and in the future will
be managed through Gitlab.

Improving visibility, specially of the WIP, is a key step towards:

 * Being able to forecast based on facts/data instead of simply estimate.

 * Better management of expectations as individuals and as a project.

 * Increase transparency, which provides many benefits, specially working in
the open.

 * Reduce the threshold for potential new contributors to jump on high impact
tasks.

 * Many others...

## Description

The proposal is to make (better) use of the following items on Gitlab:

 * Milestones: check mail [Add Gitlab features to BuildStream 01/04]

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

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

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

in a coherent and structured way.

## Other repos

Those proposed enhancements that are only applicable to the BuildStream
Project will be rolled out to the rest of the Projects (repos) later on. In
the case of the topic labels, a per project study needs to be carried on.
Agustin will talk directly with the Master of each one of the Projects about
it.

## Risk management

The following risks apply to the proposal:

 * Unrealistic/fixed expectations of commitment:
        * By assigning severity labels to issues and MR, some might imply that
there is a direct relation between the assigned values and time to completion.
                * Mitigation: in the policy document it will be clear that there is no
relation between severity and time to completion.
        * The usage of the metadata fields Due Date and Start Date in issues, MR
and milestone are taken as commitments.
                * Mitigation: in the policy document it will be clear that there are
no explicit or implicit commitments. The values assigned to these fields are
taken as estimations or, in the best scenario, forecast, so they always have
associated uncertainty. They are also used for visualization and notification
purposes.

 * Perception of assignment or handling of metadata as mandatory, specially in
the case of community members.
        * The usage of metadata and workflows consumes time and requires a certain
level of familiarity with the general usage policy. In some cases, it will be
a matter of interpretation. There is a risk that people perceptive that the
usage
of the proposed elements (milestones, labels, boards and templates) is
mandatory
                * Mitigation: the adoption of these policies will be promoted, not
enforced, providing the chance to newcomers and occasional contributors to not
follow them, focusing first on the contributions themselves. Templates will be
our friend here.[BuildStream prioritizes contributions over processes.

 * Unjustified increase of the maintenance effort.
        * Applying these enhancements require an additional and sustained effort
making easier to scale up but harder to scale down the management effort,
potentially affecting sustainability.
                * Mitigation: the proposal has been designed to limit the day to day
maintenance effort and to ensure that if the management capacity drops, the
project can handle it while keeping visibility in better shape than it is
today.

## Next steps and final considerations

After reading this proposal, the next steps should be:

 * Discussion of the proposal. Consensus generation.

 * Creation of a simple policy document and publication on the wiki to support
the changes.

 * Implementation of the changes. Test.

 * Communication of the changes.

 * Evaluation of the changes and their impact.

I would like to point some final considerations:

 * After the changes are applied, we need to assume that some small
improvements might be needed in order to better adapt the proposal to reality.

 * Once these changes are settle, my next goal is to define a roadmap workflow
so there is a simple and easy way to visualise the process to turn requests
into engineering tasks. 

 * Many additional improvements can be done but we need to walk before
running. The above proposal is what I consider the minimum to achieve the
goals with the lowest impact on developers.

 * I understand that this proposal is long and tedious but it is relevant to
you so please have a look. I will answer the questions immediately. I will go
over the comments and opinions in a few days, giving time for everybody to
distill it.

[1] https://gitlab.com/BuildStream/nosoftware/alignment/blob/master/
proposal_to_apply_Gitlab_features_to_BuildStream.md

Best Regards
--
Agustín Benito Bethencourt
Principal Consultant
Codethink Ltd
_______________________________________________
Buildstream-list mailing list
Buildstream-list gnome org
https://mail.gnome.org/mailman/listinfo/buildstream-list

--

Cheers,

Sander