Triage includes: - Labeling issues - Responding to issues - Closing issues

Daily Triage

Daily triage has two goals:

  1. Responsiveness for new issues
  2. Responsiveness when explicitly requested information was provided

It covers:

  1. Issues without a priority/ label
  2. triage/needs-information issues which the user has followed up on, and now require a response.

The most important level of categorizing the issue is defining what type it is. We typically want at least one of the following labels on every issue, and some issues may fall into multiple categories:

  • triage/support - The default for most incoming issues
  • kind/bug - When it’s a bug or we aren’t delivering the best user experience

Other possibilities: - kind/feature- Identify new feature requests - kind/testing - Update or fix unit/integration tests - kind/cleanup - Cleaning up/refactoring the codebase - kind/documentation - Updates or additions to trivy documentation

If the issue is specific to a driver for OS packages or libraries:

co/[driver for OS packages]

  • co/alpine
  • co/amazon
  • co/debian
  • co/oracle
  • co/photon
  • co/suse
  • co/ubuntu

co/[driver for libraries of programming languages]

  • co/bundler
  • co/cargo
  • co/npm
  • co/yarn
  • co/pipenv
  • co/poetry

Help wanted?

Good First Issue - bug has a proposed solution, can be implemented w/o further discussion.

Help wanted - if the bug could use help from a contributor

Prioritization

If the issue is not triage/support, it needs a priority label.

priority/critical-urgent - someones top priority ASAP, such as security issue, user-visible bug, or build breakage. Rarely used.

priority/important-soon: in time for the next two releases. It should be attached to a milestone.

: 2-4 releases from now

priority/backlog: agreed that this would be good to have, but no one is available at the moment. Consider tagging as help wanted

Weekly Triage

Weekly triage has three goals:

  1. Catching up on unresponded issues
  2. Reviewing and closing PR’s
  3. Closing stale issues

Post-release triage occurs after a major release (around every 4-6 weeks). It focuses on:

  1. Closing bugs that have been resolved by the release
  2. Reprioritizing bugs that have not been resolved by the release
  3. Letting users know if we believe that there is still an issue

This includes reviewing:

  1. Every issue that hasn’t been touched in the last 2 days
  2. Re-evaluation of long-term issues
  3. Re-evaluation of short-term issues

Responding to Issues

A sample response to ask for more info:

Then: Label with triage/needs-information.

If you think a release may have resolved an issue, ask the author to see if their issue has been resolved:

Then: Label with triage/needs-information.

Issues typically need to be closed for the following reasons:

  • The issue has been addressed
  • There has been a lack of information over a long period of time

In any of these situations, we aim to be kind when closing the issue, and offer the author action items should they need to reopen their issue or still require a solution.

Samples responses for these situations include:

Then: Close the issue

Then: Label with triage/duplicate and close the issue.

If an issue hasn’t been active for more than four weeks, and the author has been pinged at least once, then the issue can be closed.

Then: Close the issue.

Help Wanted issues

We use two labels help wanted and to identify issues that have been specially groomed for new contributors.

If an issue has these labels but does not satisfy the guidelines, please ask for more details to be added to the issue or remove the labels.