How to run a remote bug bash
A bug bash is an hour where the whole team uses the product on purpose and writes down everything that looks wrong. On a remote team it usually turns into a video call where people narrate what they see, and a shared doc that fills up with half-sentences nobody can reproduce a week later.
Run it from one channel instead. Write a short brief, file one thread per bug, keep a voice room open for the hour, and triage before the day ends.
The usual way
A remote bug bash often looks like this.
- The narrated call. Everyone is on video. Someone says "oh, that's weird" and three people ask "where?" at once.
- The shared doc. Forty lines of notes like "button broken on settings?" with no steps, no screenshot and no name.
- Duplicates. Four people find the same bug and write it down four different ways.
- The lost list. Triage happens next week, if at all. By then nobody remembers what "settings thing" meant.
A format for a distributed team
1. Make one channel for the bash
Create a channel for the bug bash a few days ahead, named after the release or area you are testing. Everyone taking part joins it. Every bug, question and screenshot goes there.
2. Post a brief and pin it
The brief is one message. Keep it short enough to read in a minute.
- What to test. The feature, the flow or the build. A link to where it runs.
- Who tests what. Split the area so people do not all start on the same screen.
- The time. Start and end, in one time zone everyone agrees on.
- How to file. One message per bug, in the format below.
3. One message per bug, one thread per message
Each bug is its own top-level message in the channel. Keep the shape the same every time.
- Where: Settings, notifications tab
- Steps: Turn off email, reload the page
- Expected: Email stays off
- Saw: Email is back on after reload
- Screenshot: attached
Anything else about that bug goes in its thread: "same on my machine", a second screenshot, a question. Duplicates become a reply on the first report instead of a new line. When the hour is over, the channel is a clean list with one message per bug.
4. Keep a voice room open for the hour
Some bugs are faster to show than to write. Talk in a walk-in voice room beside the channel while the bash runs.
People walk in when they want a second pair of eyes and walk out when they go back to testing. No one has to sit on a call to take part. Anything worked out out loud still ends up written in the bug's thread.
5. Triage the same day
Right after the bash, the person running it goes through the channel top to bottom. For each bug, reply in its thread with one of three outcomes.
- Fix. It goes to the tracker, with an owner. Link the ticket in the thread.
- Not a bug. One line on why.
- Later. It goes on a list with a date to look again.
Triaging the same day means the person who filed the bug is still around to answer a question about it.
Make it repeatable
- Reuse the brief. The next bug bash starts from the last one's pinned message.
- Rotate who runs it. The person running triage learns the product fastest.
- Log the calls. "Not a bug" is a decision. Write it down with the reason using the format in How to keep a decision log in team chat.
- Close the loop. When a fix ships, reply in the bug's thread with a link so the person who found it sees it land.
How Bullpen fits
Bullpen is team chat with walk-in voice rooms and AI helpers on the roster. A bug bash can live in one channel from the brief to the last triage reply.
Each bug is a thread. The report, the duplicates, the screenshots and the outcome sit together, in order.
The hour happens in the channel's walk-in voice room. It stays open beside the channel. People walk in to show a bug and leave when they are done.
Wren writes the notes. Wren is an AI helper. In that walk-in voice room, Wren posts notes and action items back to the channel the room belongs to, so a bug found out loud still lands in writing.
Nix keeps the "later" list honest. When a bug goes on the later list with a date, mention Nix in its thread and the reminder arrives in the channel on the day. How to keep track of follow-ups in team chat covers the details.
Scout remembers what was found. Scout is an AI helper on the same roster. Weeks later, mention Scout and ask whether anyone reported the notification bug. Scout answers from what was said and links the message it came from.
Try it before your next release
Pick one feature you are about to ship, make a channel for it, and pin a brief with a start time and the bug format above.