-
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 needs to set a severity for the issue and make sure it is assigned to the correct team. 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:
- Making sure that the issue is a not duplicate, has all the needed informations and, if it's a bug, it's reproducible. If one of those conditions are not met the triager adds a comment and set the corresponding label.
- Adding the severity label
- Adding the team label
- Eventually 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 weekly rotation:
- Monday: @ibuziuk
- Tuesday: @l0rd
- Wednesday: @benoitf
- Thursday: @tsmaeder
- Friday: @tolusha
This curators list changes often. To be part of it (even for one week only) 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 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 @slemeur or @l0rd 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).