Issue Triage

Overview

Summary of the issue triage methodology used for RAPIDS projects.

Triage goals

RAPIDS projects are continuously triaging new issues and re-triaging existing issues frequently. This is to ensure that high priority issues are remedied in a timely manner and the community receives frequent updates on a filed issue.

Triage process

Timing

• Label and prioritize new issues within 2 business days
• Re-prioritize existing issues every week using the project’s issue tracking boards

Tracking boards

For each project there are 3 issue tracking boards and 1 release tracking board:

• Bug Squashing - track and prioritize bugs
• Feature Planning - track and prioritize feature requests
• Other Issues - track documentation, questions, and other issues
• Release - tracks the progress of the current release

Bug Squashing, Feature Planning and Other Issues are permanent tracking boards, and are used as the basis for release planning. The Release board is not permanent and is closed once a release is completed. The example boards above are from the cuDF project.

Each permanent project board (Bug Squashing, Feature Planning,and Other Issues) has the following columns:

See Release Board for the column definition that pertain to the Release Board.

IMPORTANT: In leveraging the tracking boards for issue management, project leads can schedule issues by placing them in the appropriate column and then prioritize issues by dragging & sorting the issues from highest priority at the top of the column to lowest at the bottom. We can also use labels on the issues/PRs to filter and prioritize work.

By placing the issues in one of these permanent boards (Bug Squashing, Feature Planning, or Other Issues) filers and the community will see updates to the issue and can get a sense of when they can expect feedback. For example, on a given issue a user may see Future release in Other Issues and this allows the filer or the community to comment on if they believe the issue should be addressed faster.

Process cycle

The general process cycle for every issue is:

                                                  /------------> Hotfix --> Assign developer --> Link to PR --> Automatically close issue on PR merge
                                                  |
New issue filed --> Initial triage --> Prioritize & schedule --> Next release --> Prioritize in release --> Assign developer --> Link to PR --> Automatically close issue on PR merge
                                                  |
                                                  \------------> Future release --> Re-prioritize every week

Issues can be closed during the Initial triage step and will be appropriately documented as to why. Examples include: duplicate issues, issues determined to be out of scope, and/or issues that won’t be fixed.

New issue filed

New issues are typically filed with an issue template from the project. This automatically labels an issue with the type of the issue and the ? - Needs Triage label. This helps identify and move issues to the correct project boards for triage.

For issues not using the issue template, these should be marked with the ? - Needs Triage label and correct issue type label. Once labeled they should be moved to the appropriate project board for the given issue type.

Finding issues

Each tracking board type has a filter that can be used on when using the Add cards feature. This limits the results displayed to those that are for the tracking board and does not show pull requests.

Initial triage

Project Leads - Daily

1. Ensure the issue type is correct, i.e. is the issue really a bug or is it a feature request?
2. Review the content of the issue, has the filer provided all of the needed information for that issue type? If not, ask for clarification.
3. Add any relevant project labels like cuda, python, etc.
4. Consider adding good first issue or help wanted labels to the issue if applicable.
5. Remove the ? - Needs Triage label.
6. Move issue to its associated tracking board. This will place the issue in the Needs prioritizing column of that board and read for the next phase.

Prioritize & schedule

Once issues have been triaged, we can prioritize and schedule them for a release.

IMPORTANT: By leveraging the tracking boards for issues, project leads can schedule issues by placing them in the appropriate column and then prioritize issues by dragging & sorting the issues from highest priority at the top of the column to lowest at the bottom.

Project Leads - Daily

1. For each issue in the Needs prioritizing column, review the issue and prioritize it.
2. For issues added to Hotfix and Next release columns follow the steps below.
3. Repeat this process for all 3 tracking boards.

Project Leads - Weekly

1. Archvie all issues in the Closed column.
2. Review all issues in each column of Next release, Future release, and Backlog to make sure issues are still scheduled appropriately.
3. Prioritize any issues in Future release, and Backlog columns. Hotfix and Next release do not need to be re-prioritized as they should be in active development already.
4. Discuss the status of all issues with the team in Hotfix and Next release columns to ensure development progress is being made and there are no blockers.
5. Repeat this process for all 3 tracking boards.

Hotfix

1. Verify the issue is a hotfix.
2. Identify the project lead(s) needed to resolve the hotfix.
3. Host a meeting about the proposed hotfix with the stakeholders and operations to determine the path forward.
4. Assign a developer or team to fix the issue ASAP.

Next release

1. Ensure each issue is added to the release board project.
2. Communicate to the team the priority of the issue.
3. Update the issue on the release board with the agreed upon priority.
4. Based on priority of the issue assign a developer or wait for other higher priority issues to be completed first.

Assign developer

Developers should be assigned to issues they are responsible for delivering. Try to limit overcommitting developers. A general rule is to limit active development to 5 or fewer issues.

IMPORTANT: This is crucial for community involvement as an assigned issue looks like the issue is covered and won’t receive any input or help.

Link to PR

Every pull request should have the issue number in the descriptions of the PR with Addresses #[issue number] so when the PR is merged the issue that created the PR will automatically close as well.