Template
Public bug tracker board template
A public bug tracker template for Looph: statuses, tags and what to ask reporters for, kept apart from your feature requests and set up step by step.
Teams that want bug reports separated from feature requests, with triage by impact that reporters can follow.
- Statuses
- 5
- Tags
- 5
- Things to ask for
- 5
- Setup steps
- 7
Use this template
Copy the setup, import the starter posts
Two ways to start from this template today: copy the checklist below into your setup notes, and import the starter CSV into a new board from the Posts page of your team area. The file holds this page's example posts, with each status mapped to Looph's built-in name so the importer accepts it; delete them before you share the board.
Columns: title, details, status. 3 example posts.
Setup checklist
Public bug tracker board template (looph.ing/templates/bug-tracker-board) Statuses (the Statuses page in the team area): - Rename "Open" to "Reported" - Rename "Under review" to "Confirmed" - Keep "In progress" - Rename "Complete" to "Fixed" - Rename "Rejected" to "Won't fix" Statuses are shared by every board in a workspace, so a rename or a hidden status shows on all of them. If this board sits beside your feature requests, renaming Complete to Fixed also renames Shipped there, so pick labels that read well on both, such as Released. Tags: - Crash - Performance - Visual/UI - Data - Login/Auth Board description: List the steps to reproduce, what you expected and what happened, and your browser, OS and app version. Say whether it blocks your work. Ask for in the details: - The symptom as a title - Steps to reproduce - How bad it is - Browser, OS and app version - A link to a screenshot Setup steps: 1. Create a board called Bug reports, choose Public or Private, and paste the prompt above into the board description. 2. If reports might contain customer data, turn on Require approval before posts go live, so each one waits in a queue until a moderator approves it. 3. Rename the statuses as listed and create the five tags. 4. Connect Slack and subscribe your support triage channel to new posts and status changes on this board. 5. On Starter or above, connect Jira or GitHub and link each confirmed report to its issue, so the post moves to In progress and then Fixed as the issue does. 6. Invite the engineers and support leads who triage bugs, and assign each confirmed bug to an owner from the inbox. 7. Announce fixes worth announcing in a changelog entry of type Fixed, linked to the report, so its voters hear it is fixed.
Templates aren't applied automatically yet: you set the board up yourself by following the steps on this page. One-click templates are coming soon.
Fit
When to use this template
A good fit when
Customers report bugs you then have to chase for details, and several people report the same bug through different channels. A public bug board shows reporters that a bug is already known, lets them vote to say it affects them too, and lets them follow it until it is fixed.
It works best as a second board beside your feature requests, so how badly a bug hurts drives triage while votes drive feature planning.
Pick something else when
It does not replace your engineering issue tracker. Fix work stays in Jira or wherever your engineers already are; the board is the customer-facing side. From Starter up, link each report to its Jira or GitHub issue and the post moves to Fixed when the issue is done; on Free, a teammate moves it by hand.
Security vulnerabilities, and any report that could expose customer data, should never sit on a public board. Handle those through a private channel, or run the whole tracker as a private board.
What's inside
Statuses, tags and what to ask for, and why each one is there
Looph has a fixed set of statuses that you can rename, recolour, reorder and hide, but not add to; each status below says which built-in one to use. Posts are a title plus details, so the last list is what to ask for in the details.
Statuses
- ReportedRename Open
- Where new posts start. Nobody on your side has reproduced it yet, and the label should not imply more than that.
- ConfirmedRename Under review
- A teammate has reproduced the bug. For a reporter this is the most reassuring update, because it says the problem is real and not on their machine. Move a post here after reproduction, not after reading it.
- In progressBuilt-in status
- A fix is being worked on. Your team moves the post by hand, or, from Starter up, links it to a Jira or GitHub issue so it follows along.
- FixedRename Complete
- The fix is released and voters can be told. If it is worth announcing, link the post from a changelog entry of type Fixed.
- Won't fixRename Rejected
- For behaviour that is intended, too rare to justify the risk of changing, or made obsolete by other work. Say which in a public comment so the reporter knows it was considered.
Statuses are shared by every board in a workspace, so a rename or a hidden status shows on all of them. If this board sits beside your feature requests, renaming Complete to Fixed also renames Shipped there, so pick labels that read well on both, such as Released.
What to ask for in the details
- The symptom as a title
- Ask for the symptom, such as "Export button does nothing in Safari". That is what the next person with the same problem will type, and similar titles surface as they do.
- Steps to reproduce
- This decides whether a bug can move to Confirmed. Numbered steps from a known starting point save a round trip of follow-up questions.
- How bad it is
- Ask reporters to say whether it blocks their work, costs them data or is cosmetic. A data-loss bug with two votes outranks a glitch with forty. A dedicated severity field is coming soon with custom fields.
- Browser, OS and app version
- Most bugs that cannot be reproduced turn out to depend on one of these.
- A link to a screenshot
- Often clearer than any description. File attachments are coming soon; until then, ask for a link.
Custom fields and file attachments are coming soon. Until then, a post is a title plus up to 5,000 characters of details.
Suggested board description
Put a line like this in the board description, so people know what to include: “List the steps to reproduce, what you expected and what happened, and your browser, OS and app version. Say whether it blocks your work.”
Tags
- Crash
- Performance
- Visual/UI
- Data
- Login/Auth
Tags group bugs by type rather than by internal team. They are shared across the workspace, applied by your team, and reporters can filter the board by them. Filter the inbox by a tag and assign those posts to whoever owns that area; the assignee is notified.
Setup
Set it up in Looph
Each step in order, with the guide that covers it.
- 01
Create a board called Bug reports, choose Public or Private, and paste the prompt above into the board description.
- 02
If reports might contain customer data, turn on Require approval before posts go live, so each one waits in a queue until a moderator approves it.
- 03
Rename the statuses as listed and create the five tags.
- 04
Connect Slack and subscribe your support triage channel to new posts and status changes on this board.
Setup: Slack integration
- 05
On Starter or above, connect Jira or GitHub and link each confirmed report to its issue, so the post moves to In progress and then Fixed as the issue does.
Setup: Jira integration
- 06
Invite the engineers and support leads who triage bugs, and assign each confirmed bug to an owner from the inbox.
- 07
Announce fixes worth announcing in a changelog entry of type Fixed, linked to the report, so its voters hear it is fixed.
Illustrative examples
Example posts
Made-up posts that show what a useful entry on this board looks like. They are not from real customers.
Example · Data
CSV export stops at 1,000 rows
Steps: open Reports, choose the last 12 months, click Export. The file always ends at row 1,000 although the report shows more. Chrome on macOS. Blocks our month-end report.
Confirmed
Example · Login/Auth
Password reset link says it has expired
Clicked the link less than a minute after it arrived and got an expiry message. Happened twice today in Firefox on Windows 11. Affected users cannot sign in at all.
Reported
Example · Performance
Dashboard takes about 20 seconds to load
Only in workspaces with a large number of projects. Smaller workspaces load quickly. Slows the team down every morning.
In progress
Plan
Which plan it needs
Works on Free. The template works on Free as a public board, if it is the only board you run, since Free includes 1 public board. Adding it next to a feature request board, or running it as a private board, needs Starter, which includes 3 public boards and 1 private board. Slack is included on every plan. Compare plans.
How the pieces work: Browser extension and Feedback boards. Teams running this workflow: Feature voting and roadmaps for mobile app teams.
More templates
Other starting points
Design feedback board template
Design and product teams collecting structured critique on in-progress work from stakeholders or users.Beta feedback board template
Teams running a private or invite-only beta that need structured, votable feedback before a general release.Internal IT request board template
Internal IT and operations teams that need a searchable, votable alternative to a ticketing spreadsheet.Feature request board template
Product teams that need a single public place to collect and prioritize customer-driven feature ideas.
Related
The features and reading behind this template
Start collecting feedback in five minutes
Free forever on one board, with unlimited members and a 14-day Business trial. No credit card, no sales call.
Unlimited members · Published prices · Cancel anytime