diff options
author | Mek Stittri <mstittri@gitlab.com> | 2018-04-13 00:41:09 -0700 |
---|---|---|
committer | Mek Stittri <mstittri@gitlab.com> | 2018-04-13 13:10:14 -0700 |
commit | 7e3b4764cfefe760cb0fc408c2a27e7a054e2b2f (patch) | |
tree | 8463617d3462a0b296aced7262124a741ea32b62 /CONTRIBUTING.md | |
parent | 160f1fd225944b4cedd9d5223cdc55b2f3ed0ea7 (diff) | |
download | gitlab-ce-7e3b4764cfefe760cb0fc408c2a27e7a054e2b2f.tar.gz |
Defined priority label for bugs
- Clearly define new priority issue for bugs
- Clarrified existing priority label => Milestone labels
Diffstat (limited to 'CONTRIBUTING.md')
-rw-r--r-- | CONTRIBUTING.md | 35 |
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") |