summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMek Stittri <mstittri@gitlab.com>2018-04-13 00:41:09 -0700
committerMek Stittri <mstittri@gitlab.com>2018-04-13 13:10:14 -0700
commit7e3b4764cfefe760cb0fc408c2a27e7a054e2b2f (patch)
tree8463617d3462a0b296aced7262124a741ea32b62
parent160f1fd225944b4cedd9d5223cdc55b2f3ed0ea7 (diff)
downloadgitlab-ce-7e3b4764cfefe760cb0fc408c2a27e7a054e2b2f.tar.gz
Defined priority label for bugs
- Clearly define new priority issue for bugs - Clarrified existing priority label => Milestone labels
-rw-r--r--CONTRIBUTING.md35
1 files changed, 24 insertions, 11 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 9c8fdc1275b..918e02893e3 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -126,7 +126,7 @@ Most issues will have labels for at least one of the following:
- Type: ~"feature proposal", ~bug, ~customer, etc.
- Subject: ~wiki, ~"container registry", ~ldap, ~api, ~frontend, etc.
- Team: ~"CI/CD", ~Discussion, ~Edge, ~Platform, etc.
-- Priority: ~Deliverable, ~Stretch, ~"Next Patch Release"
+- Milestone: ~Deliverable, ~Stretch, ~"Next Patch Release"
All labels, their meaning and priority are defined on the
[labels page][labels-page].
@@ -185,10 +185,10 @@ indicate if an issue needs backend work, frontend work, or both.
Team labels are always capitalized so that they show up as the first label for
any issue.
-### Priority labels (~Deliverable, ~Stretch, ~"Next Patch Release")
+### Milestone labels (~Deliverable, ~Stretch, ~"Next Patch Release")
-Priority labels help us clearly communicate expectations of the work for the
-release. There are two levels of priority labels:
+Milestone labels help us clearly communicate expectations of the work for the
+release. There are three levels of Milestone labels:
- ~Deliverable: Issues that are expected to be delivered in the current
milestone.
@@ -203,16 +203,29 @@ Each issue scheduled for the current milestone should be labeled ~Deliverable
or ~"Stretch". Any open issue for a previous milestone should be labeled
~"Next Patch Release", or otherwise rescheduled to a different milestone.
-### Severity labels (~S1, ~S2, etc.)
+### Bug Priority labels (~P1, ~P2, ~P3 & etc.)
+
+Bug Priority labels help us define the time a ~bug fix should be completed.
+This label documents the planned timeline & urgency which is used to measure against our actual SLA on delivering ~bug fixes.
+
+| Label | Estimate time to fix | Guidance |
+|-------|--------------------------------------------------|----------|
+| ~P1 | Immediate hotfix to production | This would normally correspond to a S1 severity below |
+| ~P2 | The current milestone (regular & patch releases) | The issue is (almost) guaranteed to occur in the near future |
+| ~P3 | The next milestone (regular & patch releases) | The issue is likely to occur in the near future |
+| ~P4 | The next 2 to 4 milestones (regular & patch releases) | The issue _may_ occur but it's not likely |
+| ~P5 | Anything we know will not be done within the next quarter | The issue is prominent but does not impact user workflow and a workaround if any is well documented |
+
+### Bug Severity labels (~S1, ~S2, ~S3 & etc.)
Severity labels help us clearly communicate the impact of a ~bug on users.
-| Label | Meaning | Example |
-|-------|------------------------------------------|---------|
-| ~S1 | Feature broken, no workaround | Unable to create an issue |
-| ~S2 | Feature broken, workaround unacceptable | Can push commits, but only via the command line |
-| ~S3 | Feature broken, workaround acceptable | Can create merge requests only from the Merge Requests page, not through the Issue |
-| ~S4 | Cosmetic issue | Label colors are incorrect / not being displayed |
+| Label | Meaning | Example |
+|-------|-------------------------------------------------------|---------|
+| ~S1 | Outage, broken feature with no workaround | Unable to create an issue. Data corruption/loss. Security breach. |
+| ~S2 | Broken Feature, workaround too complex & unacceptable | Can push commits, but only via the command line. |
+| ~S3 | Broken Feature, workaround acceptable | Can create merge requests only from the Merge Requests page, not through the Issue. |
+| ~S4 | Functionality inconvenience or cosmetic issue | Label colors are incorrect / not being displayed. |
### Label for community contributors (~"Accepting Merge Requests")