How to run bug triage with a remote team
Bug triage is the regular pass where a team looks at new bugs and decides what happens to each one: fix it now, schedule it, or close it. The output is small. Every new bug leaves triage with a priority, an owner, or a reason it was closed.
On a remote team the deciding is rarely the hard part. The hard part is that bugs arrive everywhere, the weekly call runs long, and the reason a bug was closed lives in someone's memory. Run it in one place instead. One channel for incoming bugs, one thread per bug, a short walk-in voice room for the calls that need a conversation, and every decision written where the bug was reported.
The usual way
Remote triage often looks like this.
- Bugs in five places. A DM here, a comment on a doc there, a screenshot in a random channel.
- The hour-long call. Eight people read a list together, and most of them have nothing to say about most of the bugs.
- The silent close. A bug gets marked won't-fix, and the person who reported it never hears why.
- The repeat report. The same bug comes back a month later, and nobody can find the first conversation.
A format for a distributed team
1. One channel for incoming bugs
Make a channel for bug reports and pin one message at the top. Same shape every time.
- How to report: what a report needs, in four lines.
- When triage happens: the day and time of the weekly pass.
- Who triages: the person on triage duty this week.
- What happens next: every report gets a reply with a decision.
Point everyone there. When a bug shows up somewhere else, the reply is a link to the channel.
2. One message per bug, in four lines
Each bug is a new message in the channel:
- What happened. One sentence.
- What should have happened. One sentence.
- How to see it. Steps, a link, or a screenshot.
- Who it affects. One person, one team, or everyone.
Questions and extra detail go in that bug's thread. By triage time, each thread holds everything needed to decide.
3. Triage asynchronously first
The person on triage duty reads every new thread before the weekly pass and replies to each one with a proposed decision:
- Fix now. It blocks someone today. Name an owner.
- Schedule. It matters, but not this week. Say when.
- Close. Say why in one line: duplicate, expected behaviour, or not worth the cost.
Anyone who disagrees replies in the thread. Most bugs are settled here, without a meeting, and people in other time zones get the same say.
4. Settle the hard calls in a walk-in voice room
A few bugs will not settle in a thread. Two people disagree on severity, or the fix touches another team's work. Open a walk-in voice room at the usual triage time and post the list of open threads.
Only the people with a stake walk in. Everyone else keeps working. Fifteen minutes on three bugs beats an hour on thirty.
5. Close the loop in the thread
Every decision goes back into the bug's own thread, in one line. The reporter sees the outcome where they reported it, and the next person who hits the same bug finds the decision with one search.
Keep it healthy week to week
- Rotate triage duty. A different person each week, posted in the pinned message. Everyone learns the product's rough edges.
- Link duplicates, do not delete them. Reply in the new thread with a link to the old one. The second report is still evidence of how often it happens.
- Review the closed list once a quarter. Some "not worth the cost" bugs get more expensive with time.
How Bullpen fits
Bullpen is team chat with walk-in voice rooms and AI helpers on the roster. Triage can live in one channel, from the first report to the last decision.
Every bug is a thread. The report, the questions, and the decision stay together.
Hard calls happen in a walk-in voice room. The room sits beside the channel, so joining is a click, not an invite.
Wren writes the notes. Wren is an AI helper. In a walk-in voice room, Wren posts notes and action items back to the channel the room belongs to, so the reasoning behind a hard call lands next to the bugs it was about.
Scout finds the first report. Scout is an AI helper on the same roster. Mention Scout and ask whether a bug has been reported before. Scout answers from what was said and links the message it came from. Searchable team chat covers how that works.
Nix keeps scheduled fixes on time. Mention Nix in a bug's thread and ask for a reminder on the day the fix is due. The reminder arrives in that thread. How to keep track of follow-ups in team chat covers the details.
Try it this week
Make a bugs channel and pin the four-line message above.