diff --git a/docs/decisions/0015-severity-labels.md b/docs/decisions/0015-severity-labels.md
new file mode 100644
index 00000000..81a53c67
--- /dev/null
+++ b/docs/decisions/0015-severity-labels.md
@@ -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.