Issues: Labeling guideline

This document describes how the project uses different labels and what they mean.

Rules:

• Every issue should have exactly one kind label.
• Only issues with kind/user-story, kingd/task or kind/bug can be added into the sprint
• Issues can have multiple area/* labels

Kind

We use kind/*labels to categorize and organize issues and pull requests based on their nature or type. One issue or PR can have only one kind/ label.

• kind/epic - Big user story that needs to be broken down. Epics group together bugs, stories, and tasks to show the progress of a larger effort. It usually represents a significant deliverable, such as a new capability or experience.
• kind/user-story - Smallest unit of work that needs to be done and is end user-facing. It helps explain the feature from an odo user's point of view. User story issues should also contain a list of Acceptance criteria that helps identity what it means to complete this user story.
• kind/task - Unit of work that needs to be accomplished but is not end-user facing.
• kind/bug - A bug is a problem that negatively effects one or more functions.
• kind/feature - A request directly filed by a user. Feature Requests come from the user and the scope and size may not be clear. Feature Requests must be groomed into User story or Task before they can be worked on.

Area

area/* labels are used to categorize issues or pull requests based on the specific area of the project. One issue or PR can have multiple area/ labels.

• area/testing - Issues or PRs related to testing, Quality Assurance or Quality Engineering
• area/dependency - Issues or PRs related to dependency changes. This label is also used on all @dependabot PRs
• area/licensing - Issues or PRs related to licensing
• area/Linux - Issues or PRs specific to Linux
• area/Windows - Issues or PRs specific to Windows
• area/MacOS - Issues or PRs specific to MacOS
• area/kubernetes - Issues or PRs specific to Kubernetes
• area/openshift - Issues or PRs specific to OpenShift
• area/UX - Issues or PRs related to User Experience
• area/registry - Issues or PRs related to devfile registry
• area/infra - Issues or PRs related to setting up or fixing things in infrastructure. Mostly CI infrastructure.
• area/deploy - Issues or PRs specific to odo deploy command
• area/outerloop - Issues or PRs related to outerloop.
• area/telemetry - Issues or PRs related to telemetry or metrics collection.
• area/dev - Issues or PRs related to odo dev command
• area/analyze - Issues or PRs related to odo analyze command or Alizer
• area/init - Issues or PRs related to odo init command
• area/log - Issues or PRs related to odo logs command
• area/describe-component - Issues or PRs related to odo describe component command
• area/documentation - Issues or PRs related to documentation or odo.dev website.
• area/refactoring - Issues or PRs related to code refactoring
• area/binding - Issues or PRs related to odo add binding command or Service Binding Operator
• area/disconnected-cluster - Issues or PRs related to disconnected cluster (clusters with restricted network access)
• area/json-output - Issues or PRs related to json output (machine readable output)
• area/release-eng - Issues or PRs related to the Release Engineering
• area/odo-on-podman - Issues or PRs related to running odo with podman.
• area/System-PZ - Issues or PRs related to System Z and System P
• area/devfile-spec - Issues or PRs related to Devfile handling and parsing .

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.