From e29d3e1897b0dbe2ea5696086ebd4cdf3764f4f1 Mon Sep 17 00:00:00 2001 From: Vincent Moutoussamy Date: Thu, 12 Oct 2023 17:31:33 +0200 Subject: [PATCH] Applying comments' suggestion Signed-off-by: Vincent Moutoussamy --- docs/decisions/0015-severity-labels.md | 62 +++++++++++++------------- 1 file changed, 31 insertions(+), 31 deletions(-) diff --git a/docs/decisions/0015-severity-labels.md b/docs/decisions/0015-severity-labels.md index 950e6b81..eea220d1 100644 --- a/docs/decisions/0015-severity-labels.md +++ b/docs/decisions/0015-severity-labels.md @@ -3,7 +3,7 @@ ## 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. +meeting which happened once every 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. @@ -22,71 +22,71 @@ Distinction between Severity and Priority: - 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 +## Requirements 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, +- Should be easy to understand and use +- Will be taken into account when prioritising our issues +- Should be compatible with the Longhorn severity labels +- Should be adaptable to other Rancher projects -## Definitions +## Considered Alternatives 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 +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) + - 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) + - 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 + - Function working but has a major issue w/ workaround - severity/4 -Function working but has a minor issue (a minor incident with low impact) + - 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) +- Blocker + - Prevents developers or testers from performing their jobs. Impacts the development process + - (Documentation) Key documentation is missing for critical testing and review +- Critical + - 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 - Major loss of function, as specified in the product requirements for this release, or existing - in the current product. + 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) + by following the documentation successful completion of fundamental tasks is unlikely +- Normal - 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. + documentation, but successful task completion is probable +- Minor + - 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 +### Outcome 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. + - 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. + - 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. +current product - severity/normal - Regular issue, some non-major loss of functionality under specific circumstances - severity/trivial - - Issue that can be viewed as minor (e.g. cosmetic, UI, easily documented). + - Issue that can be viewed as minor (e.g. cosmetic, UI, easily documented) ## Decision Outcome