-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Issue Tracking
This page describes how we track issues in the eclipse/che repository.
The Eclipse Che project relies heavily on issue labels to communicate status and responsibility. Labels are defined in a separate doc.
New issues are automatically labeled with status/need-triage by Che bot. Those issues need to be reviewed by a project committer (the curator) that will set the issue severity and area labels. We call it the triage process.
All issues labelled status/need-triage are reviewed daily by a curator and the process to triage an issue consist in:
- Verify that:
- the issue is a not duplicate
- the issue has all the needed informations
- if it's a bug, it's reproducible
- Add the severity label
- Add the area label
- If appropriate set the label good first issue
Once the triage is done the curator removes the label status/need-triage.
At the end of its working day the curator reports the triage summary in the Eclipse Che mattermost channel.
The curator changes every day and we are currently doing a bi-weekly rotation by Che team:
Week 0 (even weeks) Monday: Hosted Che Tuesday: Platform Wednesday: Deploy Thursday: Productization + Community Enabler (Sun) Friday: Controller
Week 1 (odd weeks) Monday: Plugins Tuesday: Editors Wednesday: Devex Thursday: QE Friday: TBD
To be part of the list committers can request it on Eclipse Che mattermost channel or with an email at [email protected] mailing list.
What query should we use for looking at incoming issues? We should look for:
- Issues opened today: “is:issue is:open created:>=YYYY-MM-DD”
- Issues labelled status/need-triage
- Issues with more information needed
- Issues waiting for analysis
Should the curator try to reproduce all the issues? The curator doesn’t have the time to reproduce every issue. If it takes more than 15 min he should delegate it to a team leader. We do that labelling the issue as “team/xyz” + “status/2Fanalyzing” and assigning it to the team lead.
Should the curator set the issue milestone? The curator should not set the issue milestone but, if the issue is a blocker, it should be part of current milestone. If it’s a P1 or P2 it depends on the team bandwidth (have they finished working on other P1s/P2s?) and on the risk of regressions. That said the curator may not be able to determine if it’s a blocker or not (ask @l0rd, @davidfestal @benoitf in that case) and if the corresponding team has bandwidth to work on it during the current sprint (just assign it to “team/xyz” or to a TL in that case).