Triage Process

1. Overview

New issues are filed daily, we need to quickly respond to them and identify the relative timeline for them. This is critical for us to understand bugs, as well as maintaining a strong community.

2. Scope

This document covers how to handle new issues through our issue triage process. It covers issues filed both within GitHub and external issues.

Intended audience: Developers

3. Related Processes

• Issue Types

4. Issue Triage

Initial triage

TO BE UPDATED: Initial triage will be handled on a rotating schedule aligned to the sprints. During that time, the assigned triage PiC will follow the below process Issues that do not have a Milestone value in the GitHub Project require triage.

1. Is the request valid/should it be part of cuTile?
   • If not, close as Will not complete and comment to the filer the reasoning (we want to be welcoming and encourage them to file new issues in the future)
   • If an issue is a duplicate close as Will not complete and link the duplicate in the comments
   • If they did not use one of our issue templates but they should have, close as will not complete and ask them to refile using our template
2. Ensure the issue type is correct, i.e. is the issue really a bug or is it a feature request?
   1. If it's a [Question] type issue, convert it to a discussion and answer the question or @ team members as needed
3. Review the content of the issue, has the filer provided all of the needed information for that issue type? If not, ask for clarification
   1. If it's a [Bug] is there enough info (repro, logs, env)?
   2. If it's a [FEA] is it something we want to add?
      1. If no, close as Will not complete with comments
   3. If it's a [Doc] request did the filer look in the correct spot?
4. Add any relevant project fields
5. Consider adding good first issue or help wanted labels to the issue if applicable
6. Decide the Milestone value the issue should go into
   1. This is somewhat subjective and will be reviewed as a team during release planning
   2. A good heuristic is
      1. Really important? --> Next Release
      2. Would be a significant gain? --> Priority Backlog
      3. Would be nice? --> Backlog
7. Set the Milestone in the project to the decided release, this removes it from the triage view in the projects and completes the triage

Assigning developers

Developers should be assigned to issues they are responsible for delivering. If this issue triaged is going into the current release, Try to limit overcommitting developers. A general rule is to limit active development to 5 or fewer issues.

Triaging from Non-GitHub Sources

cuTile will sometimes receive issues from outside of GitHub. The triage process is largely the same but with a slight modification:

• After making sure the issue is valid and has enough information, make a corresponding issue in the cuTile repo
  • You must sanitize any and all CI/PII
• In the initial issue, link the newly created GitHub issue

5. References/Appendix

This section is currently empty.