Issues Triaging and Labeling

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.

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 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.

Issue Estimation

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 complexity of the work, we will use exp/* labels.

Estimation	Description
est/1, 3, 5, 8, 13, 21, 40	Apply these labels to a 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.

Issue Workflows

Although there could be multiple variations in issue transitions, here is a possible and the most common workflow. 

Note: This guideline is inspired by Docker and its extension projects such as swarm.