Issues Triaging and Labeling - co-jo/pravega GitHub Wiki
An issue can have multiple labels of the following types. Typically, a properly classified issue should have:
- One label identifying its kind (kind/*).
- One or multiple labels identifying the functional areas of interest (area/*).
- Where Applicable, One label categorizing its difficulty (exp/*).
- Where Applicable, One label estimating how long it might take (est/*).
- When Applicable, Associate the issue to a milestone, i.e. sprint.
- When associated with a milestone, "One label" prioritizing how urgent the issue is.
Issue kind
| **Kind ** | Description |
|---|---|
| kind/bug | Bugs are bugs. The cause may or may not be known at triage time so debugging should be accounted for in the time estimate. |
| kind/enhancement | Enhancements are not bugs or new features but can drastically improve the usability or performance of a project component. |
| kind/feature | Functionality or other elements that the project does not currently support. Features are new and shiny. |
| kind/question | Contains a user or contributor question requiring a response. |
Functional area
| Area |
|---|
| area/api |
| area/build |
| area/controller |
| area/server |
| area/client |
| area/docs |
| area/tier1 |
| area/tier2 |
| area/performance |
| area/security |
| area/logging |
| area/testing |
Experience level
Experience level primarily defines the complexity of the issue and is also a way for a contributor to find an issue based on their skill set. Experience types are applied to the issue or pull request using labels.
| Level | Experience level guideline |
|---|---|
| exp/beginner | New to Pravega, and is looking to help while learning the basics. |
| exp/intermediate | Understands the core concepts of Pravega and looking to dive deeper into the project. |
| exp/expert | Proficient with Pravega and has been following, and active in, the community to understand the rationale behind design decisions and where the project is headed. |
Issue status
To communicate the status with other collaborators, you can apply status labels to issues. These labels prevent duplicating effort.
| Status | Description |
|---|---|
| no status | Issue has been created, not yet validated by reproducing the claimed bug or not yet accepted due to lack of justification. |
| status/accepted | Apply to enhancements / feature requests that we think are good to have. Adding this label helps contributors find things to work on. Serves as a backlog. |
| status/rejected | Apply to enhancements / requests that have been discussed and found to be unnecessary, or not aligned with Pravega roadmap. Once rejected, issue needs to be closed asap. |
| status/more-info-needed | Apply this to issues that are missing information (eventually we need to update Issue Template that requires Pravega Version, Runtime environment ..), or require feedback from the reporter. If the issue is not updated after a week, it can generally be closed. |
| status/in-progress | Apply this label if an issue has been picked up by a developer and is in design discussion/development |
| status/needs-attention | Apply this label if an issue (or PR) needs more eyes. |
Estimating issue
To plan more accurately and manage expectations of other collaborators, you can apply estimation labels to issues. These labels will help other contributors understand how much work would they need to put into. The higher number, the more work involved. For the complexity of the work, we will use exp/* labels.
| Estimation | Description |
|---|---|
| est/1, 3, 5, 8, 13, 21, 40 | Apply these labels to an issue based on how many hours it will take to complete. If an issue takes more than 40 hours, breaking down into manageable pieces is recommended. |
Prioritizing issue
When, and only when, an issue is attached to a specific milestone, the issue can be labeled with the following labels to indicate their degree of priority (from more urgent to less urgent).
| Priority | Description |
|---|---|
| priority/P0 | Urgent: Security, critical bugs, blocking issues. P0 basically means drop everything you are doing until this issue is addressed. |
| priority/P1 | Important: P1 issues are a top priority and a must-have for the next release. |
| priority/P2 | Normal priority: default priority applied. |
| priority/P3 | Best effort: those are nice to have / minor issues. |
Issue Workflows
Although there could be multiple variations in issue transitions, here is a possible and the most common workflow.
Note: We would like to thank the communities of Docker and its associated projects for setting up a great set of contribution guidelines and acknowledge that our Issue Triaging guidelines build on theirs