Skip to content

Define priority label for bugs

Mek Stittri requested to merge priority-scale-for-bugs into master

Per the discussions we had in the product/engineering meetings, we have the go-ahead to adopt a unified priority label for bugs. The discussion with the Product team is documented under https://docs.google.com/document/d/1dAs9HoAbuiRzYYvk-AFMggbN-1Hb1l6L17jMzLePbkA/edit#heading=h.en93zrg5jct

This MR defines the 4 levels of priority when triaging an defect that affects GitLab products.

Priority boils down to the urgency and timeline that we will address an issue. It is important that the whole team converges in on a unified urgency currency that Product and Engineering understands and can execute against the release timeline. We will then grade ourselves on the SLA (service level agreement) that we promise to our users. The priority marks the team's intention to when a bug should be fixed, the SLA is the actual time when the bug is fixed. This will be surfaced later from within our engineering metrics and dashboards.

See backstory on this discussion in gitlab-com/www-gitlab-com!10684 (comment 65832318)

Why is this important

  • To simplify execution and get all the teams normalize on the same unit of urgency.
  • The simpler it is to understand priority the faster we can move.
  • To display insights into engineering operations see issue gitlab-insights#1 (closed) it is very helpful to normalize and simplify the fields.

If we can get all the teams on the same Severity and Priority it will be a lot more productive. We can also have the same performance metrics across engineering.

New priority labels in the project

Bug Priority labels help us define the time a ~bug fix should be completed. Priority determines how quickly the defect turnaround time must be. If there are multiple defects, the priority decides which defect has to be fixed immediately versus later. This label documents the planned timeline & urgency which is used to measure against our actual SLA on delivering ~bug fixes.

Label Meaning Estimate time to fix Guidance
~P1 Urgent Priority The current release + potentially immediate hotfix to GitLab.com
~P2 High Priority The next release
~P3 Medium Priority Within the next 3 releases (approx one quarter)
~P4 Low Priority Anything outside the next 3 releases (approx beyond one quarter) The issue is prominent but does not impact user workflow and a workaround is documented

I have also added a link entry from the Engineering Handbook in this MR gitlab-com/www-gitlab-com!11131 (merged)

How was this new label defined

This is adapted to suit combined interests from existing priority fields from other teams.

  • Performance AP labels
  1. ~AP1 The issue is (almost) guaranteed to occur in the near future is now recommend to ~P2 The next release
  2. ~AP2 The issue is likely to occur in the near future is now recommend to ~P3 Within the next 3 releases
  3. ~AP3 The issue _may_ occur but it's not likely, ok to fix in the next few releases is now recommend to ~P3 Within the next 3 releases or ~P4 Anything outside the next 3 releases
  • Security SL labels
  1. ~SL1 Security Level 1 - Issues that present a critical security risk and must be patched before the next release is now recommend to ~P1 The current release + potentially immediate hotfix to GitLab.com
  2. ~SL2 Issues that present a moderate security risk and should be patched in the next Security Release if possible is now recommend to ~P2 The next release
  3. ~SL3 Issues that present a low security risk is now recommend to ~P3 Within the next 3 releases (approx one quarter)

An issue with no priority is considered ungroomed and needs triage (from a Priority point of view).

Other changes

I am also proposing to rename the previous priority label to Milestone labels

/cc @edjdev @yorickpeterse @smcgivern @kathyw @tommy.morgan @lbot @DouweM @timzallmann

Edited by Mek Stittri

Merge request reports