-
Notifications
You must be signed in to change notification settings - Fork 21
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
eaae805
commit d30046f
Showing
1 changed file
with
93 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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. |