Scalability Group Project Management

Project Management

The majority of our project management process is described at the Platforms level and is shared between all SaaS Platform teams. Please read this first.

This page describes the additions to the process described on the Platforms page.

The single source of truth for all work is Scaling GitLab SaaS Platforms epic. We often refer to this as our top-level epic.

Epics that are added as children to the top-level epic are used to describe projects that the team undertakes.

Project status is maintained in the description of the top-level epic so that it is visible at a glance. This is auto-generated using the epic issues summary project. You can watch a short demo of this process to see how to use status labels on the epics to make use of this automation.

Project Ownership

Each project has an owner who is responsible for delivering the project.

The owner needs to:

1. Update the status block in the epic description each week.
2. Work with others to move project issues through the boards.

Project Structure

The epic for the project must have the following items:

1. Background, including a problem statement, to provide context for people looking to understand the project.
2. Exit criteria for the specific goals of the project.
   1. These are created as issues with the exit criterion label in the epic and are linked in the description.
   2. We create these at the start of the project to allow us to keep focused on our goal, and use blocking issues to indicate the state of each exit criterion.
3. Status yyyy-mm-dd should be the final heading in the description.
   1. This enables others who are interested in the epic to see the latest status without having to read through all comments or issues attached to the epic.
   2. This heading is used to auto-generate the status information on the top-level epic.
   3. If the epic has no child-epics and a mermaid block is added, this script that runs on a pipeline will automatically generate and include an issue relationship diagram in this section. An example can be seem in this epic.
4. Start date is set to the expected start date, and updated to be the actual start date when the project begins.
5. Due date is set to be the expected end date.
   1. This should be seen as a target, and this target is re-evaluated every few weeks while the project is in progress. The date that a project actually ended is taken from the date that the epic was closed.

Issue boards

The Scalability group issue boards track the progress of ongoing work.

On the planning board, the goal is to get issues into a state where we have enough information to build the issue. However, not all issues that are workflow-infra::Ready to be built should be scheduled for development right away. Some issues may be too big, or might not be as important as others. This means not all issues that are workflow-infra::Ready on the planning board will move to the build board immediately.

Planning	Building
Planning Board	Build Board
Issues where we are investigating the work to be done.	Issues that will be built next, or are actively in development.

Labels

The Scalability teams routinely uses the following set of labels:

1. The group label, group::Scalability.
2. The team labels, team::Scalability-Observability and team::Scalability-Practices
3. Scoped workflow-infra labels.
4. Scoped Service labels.

The group::Scalability label is used in order to allow for easier filtering of issues applicable to the team that have group level labels applied.