Defined priority label for bugs
- Clearly define new priority issue for bugs - Clarrified existing priority label => Milestone labels
This commit is contained in:
parent
160f1fd225
commit
7e3b4764cf
|
@ -126,7 +126,7 @@ Most issues will have labels for at least one of the following:
|
||||||
- Type: ~"feature proposal", ~bug, ~customer, etc.
|
- Type: ~"feature proposal", ~bug, ~customer, etc.
|
||||||
- Subject: ~wiki, ~"container registry", ~ldap, ~api, ~frontend, etc.
|
- Subject: ~wiki, ~"container registry", ~ldap, ~api, ~frontend, etc.
|
||||||
- Team: ~"CI/CD", ~Discussion, ~Edge, ~Platform, 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
|
All labels, their meaning and priority are defined on the
|
||||||
[labels page][labels-page].
|
[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
|
Team labels are always capitalized so that they show up as the first label for
|
||||||
any issue.
|
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
|
Milestone labels help us clearly communicate expectations of the work for the
|
||||||
release. There are two levels of priority labels:
|
release. There are three levels of Milestone labels:
|
||||||
|
|
||||||
- ~Deliverable: Issues that are expected to be delivered in the current
|
- ~Deliverable: Issues that are expected to be delivered in the current
|
||||||
milestone.
|
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
|
or ~"Stretch". Any open issue for a previous milestone should be labeled
|
||||||
~"Next Patch Release", or otherwise rescheduled to a different milestone.
|
~"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.
|
Severity labels help us clearly communicate the impact of a ~bug on users.
|
||||||
|
|
||||||
| Label | Meaning | Example |
|
| Label | Meaning | Example |
|
||||||
|-------|------------------------------------------|---------|
|
|-------|-------------------------------------------------------|---------|
|
||||||
| ~S1 | Feature broken, no workaround | Unable to create an issue |
|
| ~S1 | Outage, broken feature with no workaround | Unable to create an issue. Data corruption/loss. Security breach. |
|
||||||
| ~S2 | Feature broken, workaround unacceptable | Can push commits, but only via the command line |
|
| ~S2 | Broken Feature, workaround too complex & 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 |
|
| ~S3 | Broken Feature, 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 |
|
| ~S4 | Functionality inconvenience or cosmetic issue | Label colors are incorrect / not being displayed. |
|
||||||
|
|
||||||
### Label for community contributors (~"Accepting Merge Requests")
|
### Label for community contributors (~"Accepting Merge Requests")
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue