Skip to content

Commit

Permalink
Add severity labels ADR
Browse files Browse the repository at this point in the history
  • Loading branch information
vmoutoussamy committed Oct 12, 2023
1 parent eaae805 commit d30046f
Showing 1 changed file with 93 additions and 0 deletions.
93 changes: 93 additions & 0 deletions docs/decisions/0015-severity-labels.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,93 @@
# Severity Labels

## Context and Problem Statement

In our current process, we are reviewing our backlog and issues in general during our Backlog Review
meeting which happened once every 4 weeks in our Release Cycle.
Thus when a new issue is created, we automatically add the label 'waiting/triage' so we can review
it during our next Backlog Review. During the Backlog Review meeting, we collectively set a priority
label (from 0-Highest to 3-Lowest) so we can prioritise our work for the next cycle.
This is not ideal as an issue can be leftover for weeks before before it's discussed during the
Backlog Review.

## Solution

To make the review and planning process easier for the Tech Lead, the Engineering Manager and
Engineers. We would like to introduce a new type of Labels: Severity.
The goal is to provide a way for the reporter of an Epic/Issue to provide an estimation of the
impact and help the team to plan an prioritise accordingly.

Distinction between Severity and Priority:
- The severity field describes the impact of a bug. And the reporter is free to set this up
- The priority field describes the importance and order in which an issue should be fixed. Priority
cannot be changed without discussing it with Joao or Vincent.

## Requierements

The severity labels:
- should be easy to understand and use,
- be taken into account when prioritising our issues,
- should be compatible with the Longhorn severity labels,
- should be adaptable to other Rancher projects,

## Definitions

The severity label describes the impact of an issue. And the reporter is free to set this up. All
issues should have a severity label set from now on.

### Longhorn

This is the current severity labels used by https://github.com/longhorn/longhorn/labels
- severity/1
Function broken (a critical incident with very high impact (ex: data corruption, failed upgrade)
- severity/2
Function working but has a major issue w/o workaround (a major incident with significant impact)
- severity/3
Function working but has a major issue w/ workaround
- severity/4
Function working but has a minor issue (a minor incident with low impact)

### openSUSE

This is the currect severity fields used for openSUSE bugs:
https://en.opensuse.org/openSUSE:Bug_definitions

- Blocker (0)
- Prevents developers or testers from performing their jobs. Impacts the development process.
- (Documentation) Key documentation is missing for critical testing and review.
- Critical (1)
- Crash, loss of data, corruption of data, severe memory leak.
- (Documentation) prescribes or doesn't warn against actions that cause data loss or corruption.
- Major (2)
- Major loss of function, as specified in the product requirements for this release, or existing
in the current product.
- (Documentation) missing, misleading, inaccurate, or contradictory information to the degree that
by following the documentation successful completion of fundamental tasks is unlikely.
- Normal (3)
- Regular issue, some non-major loss of functionality under specific circumstances
- (Documentation) missing, misleading, inaccurate, or contradictory information in the
documentation, but successful task completion is probable.
- Minor (4)
- Issue that can be viewed as trivial (e.g. cosmetic, UI, easily documented).
- (Documentation) contains stylistic or formatting issues, but functionality is not hindered.

### s3gw proposal

By using a name instead of a number, we wish to make the label very clear for the reporter and for
the team. Also this will help making the distinction between priority and severity (priority/0 and
severity/blocker for instance):
- severity/blocker
- Prevents developers or testers from performing their jobs. Impacts the development process.
- severity/critical
- Crash, loss of data, corruption of data, severe memory leak, failed upgrade.
- severity/major
- Major loss of function, as specified in the requirements for this release, or existing in the
current product.
- severity/normal
- Regular issue, some non-major loss of functionality under specific circumstances
- severity/minor
- Issue that can be viewed as trivial (e.g. cosmetic, UI, easily documented).

## Decision Outcome

0005-project-labels.md will have to be modified to include the new labels for severity.

0 comments on commit d30046f

Please sign in to comment.