How to triage bug reports from your community

Community bug reports arrive half-formed, mid-conversation, from people who are already annoyed. Triage turns that stream into a short list of fixes you can trust, and makes sure every reporter knows they were heard.

What does bug triage actually involve?

Triage means deciding four things about each report: what it is, whether you already know about it, how bad it is, and who owns it. It is not debugging. That happens later, by the owner.

How do you set up a triage routine?

1. Pick your intake channels. A #bugs channel in Discord, a shared Slack channel, GitHub Discussions, the support inbox. Reports that land elsewhere still count: copy them into your intake yourself instead of asking people to repost.
2. Book one triage slot per day. Rotate the owner weekly so one person doesn't become the permanent bug desk.
3. Classify each message. Bug, feature request, question, or not enough information yet.
4. Search before you create. Check for an existing report first.
5. Set severity and an owner.
6. Reply in the thread with the outcome.

How do you tell a bug from a feature request?

A bug is when the product doesn't do what it claims to, or stops doing what it used to. A feature request is when it works as designed and the user wants something different. For a fictional habit-tracker app:

• "CSV export drops the date column" is a bug.
• "CSV export should include my notes" is a request.
• "How do I export my data?" is a question, and maybe a sign the export button is hard to find.

If something works as designed but the design confuses people, log it as a request and keep the user's words. They're useful when you redesign.

What should you ask when a report is vague?

Ask one specific question, not a checklist. If @mira posts "sync is broken again," a request for steps, browser, OS, version and screenshots often goes unanswered. Try:

"Thanks @mira. Is this on the phone app or the web, and is it every habit or only ones you created today?"

Pick the question that splits the likely causes in half. To reproduce a bug you need what the person did, what they expected, what happened, and where. Get what you can from logs and account data, and only ask for the rest.

How do you set severity?

Severity measures impact. Priority, which you decide afterward, measures order.

More reporters can raise a bug's priority within its severity level, but they shouldn't turn a cosmetic issue into a critical one.

How should you handle duplicate bug reports?

Merge them into one report, keeping each reporter's quote and environment. Duplicates are evidence: reports from different devices often narrow down the cause faster than one detailed report. See how to handle duplicate feature requests, or paste a batch into the duplicate request finder.

What should you tell the person who reported it?

Reply where they posted, in plain words: confirmed or not, how serious, what happens next, and any workaround.

"Reproduced it, thanks. Reminders created before the 2.3 update don't fire on Android. We're fixing it this week. Until then, opening and saving the reminder once makes it work."

When the fix ships, reply in the same thread and tag the reporters. That's what makes people report the next bug instead of quietly leaving; see how to close the feedback loop.

What are the common triage mistakes?

• Debugging during triage, so the queue never gets cleared.
• Leaving "needs info" reports open forever.
• Treating upvotes as severity.
• Triaging without a named owner, so everyone assumes someone else replied.

Doing this with Sikia

Sikia listens in the Slack and Discord channels you pick and sorts each message into request, bug, question or chatter. When a bug report is vague, it asks one follow-up question in the thread and attaches the reply to the report. It also finds the existing item a report duplicates and suggests merging it, with the user's quote attached. Nothing goes public until a teammate approves it in the inbox.

FAQ

Who should own bug triage on a small team?

Rotate it weekly among the people who can judge severity, usually engineers.

Should community bug reports be public?

Public status on known bugs cuts down on repeat reports and shows you're working on them. Keep security issues and anything containing customer data private.

What do you do with bugs you can't reproduce?

Ask one follow-up, record the environment, and mark the report as needing info. If nothing new arrives after a couple of weeks, close it with a note and reopen it if a matching report comes in.