Implement the Gitlab structure

Background

Once the structure proposal is discussed and agreed ( #1 (closed) ), we will proceed to implement it. We need to consider that the discussion about the content of the templates #8 (closed) might be pending.

Task description

These are the activities to develop:

Milestones:

  • Create the new milestones.
    • Copy them from the nosoftware group.
    • Do not erase the milestones in nosoftware group. Milestones does not come across subgroups.
  • Adapt descriptions and dates to release cycle: check #22

Labels

  • Create the severity, status and bug labels at the group level.
    • Copy them from the nosoftware subgroup. * [x] Promote the critical label from the project to the group so it is not erased from the tickets. * [x] Promote the bug label from the project to the group so it does not dissapear from the tickets.
    • Erase them from the nosoftware subgroup.
  • Impact scale with only a new label called high_impact
    • Make the proposal.
    • Move all the tickets with label Critical to high_impact
    • Communicate the creation and implementation of this new scale to community members.
  • The label review will change for something else
    • Propose a new name for the label Review. New name: Verify
    • Change the label globally
    • Change the policy accordingly.

Boards:

  • Create the Group level boards
  • Create the project level boards
  • Redo the nosoftware boards and the repo (alignment and communication) boards.
  • Create a new board that related the impact scale and the severity scale.
  • Communicate the changes to the community.

Templates:

  • Create and merge the templates.
    • Issue templates: task and bug
    • Merge request template: default and option will be the same for now.
  • Communicate the availability of the templates to the community.
  • Change the default template in the buildstream repo to bug template.
    • Change the policy accordingly.
  • Correct a typo in the task template that breaks the check boxes.
  • Add the reference to the policy related with labels as comment. Currently it is not.

MR

  • New MR workflow
    • Proposal to use labels and assignees.
    • Document the new process in Hacking.bst
    • Make reference to it in the gitlab policy.

Acceptance Criteria

Edited by toscalix