Skip to content
This repository has been archived by the owner on Nov 1, 2022. It is now read-only.

IssueTriage

Jump to bottom
Michael Bridgen edited this page Apr 23, 2019 · 3 revisions

Why to triage issues

In general, issues are of two varieties:

  • a problem or question from someone using Flux
  • a reminder to do something, probably posted by a contributor

Here, we care mostly about that first variety. The aims, in descending order of importance, are to

  • help the person who logged the issue resolve their problem or question
  • help other people who may have met the same or similar problems or questions
  • keep the decks clear so we can keep development going, and respond to future issues, effectively

In the interest of not provoking Goodhart's law, I'm not putting any emphasis on particular stats.

How to triage issues

The minimal amount to figure out for a new issue is "What is the next thing that should happen?". If you figure that out, you can give the person who posted the issue a meaningful response.

Here's some meaningful responses:

  • explained what may be going on, requested fluxd logs to look for clues
  • linked to a particular FAQ entry, and asked "Does this answer your question?"
  • labelled with "bug", and indicated that we'll come up with a fix
  • labelled "blocked-needs-validation", and posted a comment saying "we're going to try and reproduce this"

Here's some responses that fall short:

  • issue labelled as "question"
  • speculated on the cause of the problem described, but didn't give a next action

Labelling an issue as bug implies that the next action is to do some work to fix the bug. If you are not sure that it's really a bug (as opposed to a bad config, or misunderstanding, say), label as blocked-needs-validation and a short comment indicating that we'll be trying to reproduce the problem.

If you're not sure on what the next step should be, you can escalate -- either @-mention someone, or bring the issue up in Slack.

Estimating the severity of an issue

As well as responding to the issue author, it will also help our future selves to have some idea of the severity or urgency of an issue. If it sounds like a bug has a chance of destroying data, or will affect many people, label it as "High user impact".

When to close an issue

Try to seek the issue author's permission to close an issue, especially if it does not have a straight-forward fix in a PR, or isn't directly addressed by an FAQ.

If it seems like an issue is hanging around, with no further action to take, close it with a quick note to the effect of "This seems to be resolved (in PR #whatever). Please re-open if you're still having the same problem."

Clone this wiki locally