Issue Triage

September 30, 2019 · View on GitHub

  • Owner: @janpio
  • Stakeholders: @pantharshit00 @divyenduz
  • State:
    • Spec: Stable ✅
    • Implementation: Fully implemented ✅

We use an Issue Triage process to handle our GitHub issues for Prisma Framework. This spec defines that process.

Triage?

Triage in this case refers to a process to understand and qualify issues, so they are actionable for our Enginerring or Product teams (a feature can be spec-ed out or implemented, a bug can be fixed).

Who

Issues are usually triaged by our Support team, and sometimes by other team members from Engineering or Product. A special case are the prisma/specs issues which are mainly handled by Product.

When

We try to triage each new issue as soon as possible. The Support team triages all issues at least daily, and tries to follow up on comments during the day as well.

How

Labeling

We use GitHub Labels to classify our issues. Each label represents some information, that is tagged to that issue by applying the label.

  1. Understand what kind of task an issue describes:
    Is it a kind/bug, kind/regression, kind/feature, kind/discussion etc.?
  2. Different kinds of issues then have a follow up process to qualify its content and actionability:
    • kind/bug and kind/regressions issues can get bug/0-needs-info and a comment asking for the missing information, bug/1-repro-available if the information required to reproduce a bug is available, or bug/2-confirmed if that available reproduction information could actually be used to reproduce and confirm the issue.

Note: Attempting a reproduction should be done even if the issue was originally raised by a team member. They should be treated as normal users as far as the triaging process is concerned.

Assigning

  • Issues that should be acted on fairly quickly can be assigned to the person that will "drive" them during the triage, otherwise assignment happens during the planning phase.

Closing

  • Issues that turn out to be duplicates of existing issues can be closed by the Support team.
  • Issues that can not be turned into actionable issues can be closed by the Support team.