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

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

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