-
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. At the end of the day, issues need to be reviewed by a project committer (triage curator) who will set the issue severity and area labels. We call this the triage process.
All issues labelled status/need-triage are reviewed daily by a curator and the process to triage an issue is:
- Verify:
- the issue is not a duplicate
- the issue has all the needed information
- if the issue is a bug, it is 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 their working day the curator reports the triage summary in the Eclipse Che mattermost channel.
The curator changes every day. We are currently doing a bi-weekly rotation by Che teams:
Week 0 (even weeks)
- Monday: @l0rd
- Tuesday: @sparkoo
- Wednesday: @themr0c
- Thursday: @nickboldt
- Friday: @amisevsk
Week 1 (odd weeks)
- Monday: @ibuziuk
- Tuesday: @dkwon17
- Wednesday: @benoitf
- Thursday: @ScrewTSW
- Friday: @Kasturi1820
You can request to be added to the curators list on the Eclipse Che mattermost channel or by sending an email to the che-dev@eclipse.org 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 reproducing an issue takes more than 15 min they should delegate it to a team. This is done through proper issue labeling, including: areas, “status/analyzing”, and assigning it to the corresponding 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 must be part of the current milestone. If it’s a P1 or P2 the milestone will depend on the corresponding team's bandwidth and on the risk of regressions. If the curator is not able to determine if an issue is a blocker or not they should (ask @l0rd, @davidfestal @benoitf).