Issues Triaging and Labeling

Prabha-Veerubhotla edited this page Jun 15, 2018 · 9 revisions

An issue can have multiple labels of the following types. Typically, a properly classified issue should have:

  1. One label identifying its kind (kind/*).
  2. One or multiple labels identifying the functional areas of interest (area/*).
  3. Where Applicable, One label categorizing its difficulty (exp/*).
  4. Where Applicable, One label estimating how long it might take (est/*).
  5. When Applicable, Associate the issue to a milestone, i.e. sprint.
  6. 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


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. 

issue 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

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.