Issues: Labeling guideline

This document describes how the project makes use of different labels and what they mean.

Kind

A kind/* label helps distinguish among the different kinds of issues:

• kind/epic - An Epic is a high level description of the desired functionality
• kind/user-story - An Epic is broken down into various User Stories. A User Story helps explain the feature from an odo user's point of view. It can have multiple Acceptance Criteria.
• kind/task - Each Acceptance Criteria of a User Story is broken down into an issue of its own called tasks. The only exception to breaking a User Story down into Tasks is when the User Story is small enough to not have only one criterion.
• kind/bug - A bug is a defect in the tooling that needs to be fixed as soon as possible.
• kind/documentation - An issue for adding/removing/modifying the content from odo's website or any other documentation such as README.md.
• kind/feature - A change that adds a new feature or deprecates/removes an existing one. Feature needs to be eventually broken down into an Epic or User Story

Milestones

Milestones are set to track odo versions (both major and minor). We generally add Epics (high-level features) to the milestones so that someone interested in knowing new stuff coming to odo has to only go through a milestone to get an idea. Example milestone - 2.3.

We also have labels for each milestone (milestone/2.3, milestone/2.4, etc.) These labels are generously applied to all Epics, User Stories, Tasks, Bugs, Documentation, and any other kind of issues to have more detailed information about what needs to be done to achieve the goal tracked by the milestone. Example milestone label - milestone/2.3. This information is helpful for the odo community to help with what's immediately important in terms of feature, bug fix, etc.

points

1 point = 1 human day. Currently, we have below labels for points:

• points/1
• points/2
• points/3
• points/5
• points/8
• points/13
• points/21

priority

• priority/Low - Nice to have issue. It's not immediately on the project's roadmap to get it done.
• priority/Medium - Nice to have issues. It's soon going to be required. Getting it done before it becomes priority/High would be a good idea.
• priority/High - Important issue; should be worked on before any other issues (except priority/Critical issue(s)).
• priority/Critical - Stop doing everything and fix this ASAP. It is making the project unusable.