Issue Tracking

This page describes how we track issues in the eclipse/che repository.

Popular Queries

Triage and Unprocessed Issue Queries

Issue Triage

Questions for Support

Milestone Status Queries

TODO @bmicklea

Issue Triage

New issues are processed and assigned a label for follow-up by the Triage owner, the Triage owner should try and keep the number of unlabelled issues to a minimum at all times while responsibly labelling each issue. A new Issue Triage owner is assigned each week (there will be a rotating schedule and if the person is in development they will be exempted from development tasks for that week - instead their primary role will be working as a support engineer).

The Issue Triage query contains

• all open issues or pull requests that...
• are unlabelled, or are non-blocker bugs...
• and have no one assigned...
• and aren’t labeled with a team/... label.

For each issue in the list, the Triage owner will analyze the issue and discuss it as necessary with other members of the team then assign a label to it as follows:

• Answerable issues > Triage owner should solve and close them.
• Invalid issues > close them and explain the reason.
• Duplicate issues > close them and add a comment: "Duplicates {issue link}."
• General questions > label them with “kind/question”.
• Docs issues > label with “kind/docs”.
• Enhancement requests > label them with “kind/enhancement” and assign to one of the team lead or product owners.
• Technical tasks and to-dos > label them with “kind/task” and assign to one of the team lead or product owners.
• Bugs > label with "kind/bug" and assign to one of the team lead or product owners. Ensure that bugs adhere to the bug template. Note that the label "severity/blocker" should only be used for bugs assigned to a milestone and only by project committers.

Technical issues assigned to a team lead that do not have a status/... label are considered unprocessed (you can find unprocessed issues queries in the common queries section of this page). To complete them the Team Lead (or optionally Triage owner) must:

• Assign it the appropriate status/ label and optionally add sprint/current-sprint label and add it to the milestone.
• Edit the title to improve it (if needed).
• Follow-up with the author (if needed).

Team Leads should keep their unprocessed backlog as small as possible at all times and try to move issues as quickly as possible to "status/open-for-dev".

Issue Labels

Issue Types

Label	Description
kind/question	Questions that haven’t been identified as being feature requests or bugs. Cannot overlap with “enhancement”, “bug”, “epic”, “task” or “docs”.
kind/enhancement	A feature request - must adhere to the feature request template. Cannot overlap with “question”, “bug”, “epic”, “task” or “docs”.
kind/epic	A long-lived, PM-driven feature request. Must include a checklist of items that must be completed, which can reference enhancements or bugs. Cannot overlap with “question”, “enhancement”, “bug”, “task” or “docs”.
kind/bug	Outline of a bug - must adhere to the bug report template. If a bug is identified during a question investigation a new issue can be created for the bug and the question closed. Cannot overlap with “question”, “enhancement”, “epic”, “task” or “docs”.
kind/task	Internal things, technical debt, and to-do tasks to be performed. Cannot overlap with “question”, “enhancement”, “bug”, “epic” or “docs”.
kind/docs	A work item tied to documentation. Cannot overlap with “question”, “enhancement”, “bug”, “epic” or “task”.
kind/planning	A work item outlining a part of our planning process - for example milestone overview issues is labelled with this.

Bug Severities

Label	Description
severity/blocker	Causes outage or prevents a fundamental feature from operating against its specification. Must be resolved immediately. Bugs can only be labelled blocker if they are assigned to a milestone. Bugs that are not blockers do not need a severity.

Dev Open Issue Status

Label	Description
status/info-needed	More information is needed before the issue can move into the “analyzing” state for engineering. Cannot overlap with “analyzing”, “open-for-dev”, “in-progress”, “code-review”, “pending-merge” or “blocked”.
status/analyzing	An issue has been proposed and it is currently being analyzed for effort and implementation approach. Cannot overlap with “info-needed”, “open-for-dev”, “in-progress”, “code-review” or “pending-merge” or “blocked”.
status/open-for-dev	An issue has had its specification reviewed and confirmed. Waiting for an engineer to accept the issue and take it into active development. Cannot overlap with “info-needed”, “analyzing”, “in-progress”, “code-review, “pending-merge” or “blocked”.
status/in-progress	This issue has been taken by an engineer and is under active development. Cannot overlap with “info-needed”, “analyzing”, “open-for-dev”, “code-review”, “pending-merge” or “blocked”.
status/code-review	This issue has a pull request posted for it and is awaiting code review completion by the community. Cannot overlap with “info-needed”, “analyzing”, “open-for-dev”, “in-progress”, “pending-merge” or “blocked”.
status/pending-merge	This issue has completed development and awaiting authorization to be merged into master. Sometimes issues can be completed, but are placed on hold to merge in “info-needed”, “analyzing”, “open-for-dev”, “in-progress”, “code-review” or “blocked”.
status/blocked	Issue that can’t be moved forward. Must include a comment on the reason for the blockage. If it’s blocked because it depends on another issue then it should include a link to the issue it depends on.Cannot overlap with “info-needed”, “analyzing”, “open-for-dev”, “in-progress”, “code-review” or “pending-merge”.

Dev Open Pull Request Status

Label	Description
status/work-in-progress	This PR is not ready to be merged. There is additional testing, development or input required.
status/merge-ready	All reviews have been finalized. The PR can be merged into master if merges are being accepted according to sprint or milestone plan.

Sprint Status

Label	Description
sprint/current-sprint	Issue is being worked in the current sprint.
sprint/next-sprint	Issue is planned to be worked in the next sprint.

Team Assignments

Label	Description
team/ide	Issue to be taken by the IDE team.
team/enterprise	Issue to be taken by the enterprise features team.
team/plugin	Issue to be taken by the plugin development team.
team/production	Issue to be taken by the production readiness team.
team/platform	Issue to be taken by the platform team.
team/pm	Issue to be taken by the product management team.

Consistent Milestones

To enable planning across repositories, we require that all related Che repositories, such as eclipse/che-parent define identical milestones.