summaryrefslogtreecommitdiff
path: root/CONTRIBUTING.md
diff options
context:
space:
mode:
authorMek Stittri <mstittri@gitlab.com>2018-07-12 21:31:17 +0000
committerMek Stittri <mstittri@gitlab.com>2018-07-12 21:31:17 +0000
commit226d4d0eaa09a035ccb4cd8e83f92ffd9af9b40c (patch)
tree05cb924999fa57b964c5abbc48e6101272b4f7a3 /CONTRIBUTING.md
parentb8450b8bd7a441728544a295c75dd2cae4b5fe19 (diff)
parent46be2ae634b34819b2f4f30e6d0f2a1ad8a66318 (diff)
downloadgitlab-ce-226d4d0eaa09a035ccb4cd8e83f92ffd9af9b40c.tar.gz
Merge branch 'polish-severity-facets' into 'master'
Polish severity level facets further See merge request gitlab-org/gitlab-ce!20572
Diffstat (limited to 'CONTRIBUTING.md')
-rw-r--r--CONTRIBUTING.md34
1 files changed, 18 insertions, 16 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 0f3b07e8392..4a1fa39b41d 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -226,24 +226,24 @@ 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.
-### Bug Priority labels
+### Priority labels
-Bug Priority labels help us define the time a ~bug fix should be completed. Priority determines how quickly the defect turnaround time must be.
+Priority labels help us define the time a ~bug fix should be completed. Priority determines how quickly the defect turnaround time must be.
If there are multiple defects, the priority decides which defect has to be fixed immediately versus later.
This label documents the planned timeline & urgency which is used to measure against our actual SLA on delivering ~bug fixes.
-| Label | Meaning | Estimate time to fix | Guidance |
-|-------|-----------------|------------------------------------------------------------------|----------|
-| ~P1 | Urgent Priority | The current release + potentially immediate hotfix to GitLab.com | |
-| ~P2 | High Priority | The next release | |
-| ~P3 | Medium Priority | Within the next 3 releases (approx one quarter) | |
-| ~P4 | Low Priority | Anything outside the next 3 releases (approx beyond one quarter) | The issue is prominent but does not impact user workflow and a workaround is documented |
+| Label | Meaning | Estimate time to fix |
+|-------|-----------------|------------------------------------------------------------------|
+| ~P1 | Urgent Priority | The current release + potentially immediate hotfix to GitLab.com |
+| ~P2 | High Priority | The next release |
+| ~P3 | Medium Priority | Within the next 3 releases (approx one quarter) |
+| ~P4 | Low Priority | Anything outside the next 3 releases (approx beyond one quarter) |
-### Bug Severity labels
+### Severity labels
Severity labels help us clearly communicate the impact of a ~bug on users.
-| Label | Meaning | Impact of the defect | Example |
+| Label | Meaning | Impact on Functionality | Example |
|-------|-------------------|-------------------------------------------------------|---------|
| ~S1 | Blocker | Outage, broken feature with no workaround | Unable to create an issue. Data corruption/loss. Security breach. |
| ~S2 | Critical Severity | Broken Feature, workaround too complex & unacceptable | Can push commits, but only via the command line. |
@@ -252,12 +252,14 @@ Severity labels help us clearly communicate the impact of a ~bug on users.
#### Severity impact guidance
-| Label | Security Impact | Availability / Performance Impact |
-|-------|---------------------------------------------------------------------|--------------------------------------------------------------|
-| ~S1 | >50% users impacted (possible company extinction level event) | |
-| ~S2 | Many users or multiple paid customers impacted (but not apocalyptic)| The issue is (almost) guaranteed to occur in the near future |
-| ~S3 | A few users or a single paid customer impacted | The issue is likely to occur in the near future |
-| ~S4 | No paid users/customer impacted, or expected impact within 30 days | The issue _may_ occur but it's not likely |
+Severity levels can be applied further depending on the facet of the impact; e.g. Affected customers, GitLab.com availability, performance and etc. The below is a guideline.
+
+| Severity | Affected Customers/Users | GitLab.com Availability | Performance Degradation |
+|----------|---------------------------------------------------------------------|----------------------------------------------------|------------------------------|
+| ~S1 | >50% users affected (possible company extinction level event) | Significant impact on all of GitLab.com | |
+| ~S2 | Many users or multiple paid customers affected (but not apocalyptic)| Significant impact on large portions of GitLab.com | Degradation is guaranteed to occur in the near future |
+| ~S3 | A few users or a single paid customer affected | Limited impact on important portions of GitLab.com | Degradation is likely to occur in the near future |
+| ~S4 | No paid users/customer affected, or expected to in the near future | Minor impact on on GitLab.com | Degradation _may_ occur but it's not likely |
### Label for community contributors