Applying comments' suggestion

Signed-off-by: Vincent Moutoussamy <[email protected]>

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