Why this matters: Your triage meeting is where the magic happens. Without a clear agenda, these meetings can turn into chaotic discussions that waste everyone’s time. This template keeps things focused and productive.

How to use it:

• Set up a recurring meeting (we recommend weekly, 30-45 minutes)
• Send this agenda out 24 hours in advance
• Assign a different person to facilitate each week (prevents burnout)
• Stick to the time limits for each section

# Bug Triage – Weekly Agenda

**Date & Time:** {{YYYY-MM-DD, HH:MM TZ}}
**Facilitator:** {{Name}}
**Attendees:** {{QA, Dev, PM, Support}}
**Objective:** Review new/open bugs, set/adjust priorities, assign owners, confirm next actions.

## 1) New & Reopened Bugs (since last triage)
For each ticket:
- ✅ Valid bug? (not duplicate / support request / third-party outage)
- 📄 Has essentials? (title, repro steps, expected vs actual, env, artifacts)
- 🧭 Severity & impact (confirm/adjust)
- 🗂 Priority & target (Now / Next sprint / Backlog)
- 👤 Owner / team
- 📝 Decision noted in ticket + triage log

## 2) Follow‑ups on Previously Triaged P1/P2
- Status, blockers, ETA; escalate if drifting.

## 3) Backlog Grooming (time‑boxed)
- Close stale/irrelevant; bubble up rising items; merge duplicates.

## 4) Risks & Themes
- Patterns (modules, devices, regressions) and preventive actions.

## 5) Decisions & Actions Recap
- P1/P2 list with owners & ETAs
- Deferred/Rejected list (with rationale)

**Next Triage:** {{Day/Time cadence}}

• Add your team’s specific roles (e.g., if you have customer support reps, include them)
• Adjust time allocations based on your team’s size and bug volume
• Include links to your triage tools (Jira, Linear, etc.)

Why this matters: Not all bug reports are actually bugs, and not all bugs are ready for triage. This checklist helps you quickly sort through incoming reports and either get them ready for discussion or ask for missing information. It’s your first line of defense against chaos.

How to use it:

• Review this for every new bug report before it hits the triage meeting
• If anything is missing, ask the reporter nicely for the information
• Use it to tag and categorize reports appropriately
• Keep responses friendly - remember, most reporters are trying to help!

# Bug Intake – Pre-Triage Screening Checklist

For each new report:
1. **Is it actually a bug?** Not a feature request, usage question, or third‑party outage.
2. **Duplicate check:** Search by title/keywords; link to canonical ticket; migrate any unique info.
3. **Reproducible?** If not, request: exact steps, environment, accounts, data sample.
4. **Minimum fields present:** Title, description, steps, expected vs actual, environment (app version, OS/Browser/Device), timestamps, attachments (screenshot, console/logs, HAR).
5. **Severity suggestion:** Critical/High/Medium/Low based on user impact; tag component.
6. **Security/Privacy?** If yes, flag `security`, restrict visibility, page on‑call if critical.
7. **Customer/Revenue sensitivity?** Tag account, ARR/plan tier, and note deadlines (launches, campaigns).
8. **Crash/Exception reports:** Attach stack trace IDs, error rate, first/last seen, affected versions.
9. **Ownership route:** Assign provisional component/team; leave for meeting if unclear.
10. **Comms:** Acknowledge reporter; set expectations on next update.

Why this matters: A good bug report is like a gift to your future self (and your team). It contains all the information needed to understand, reproduce, and fix the issue quickly. Bad reports lead to endless back-and-forth and frustrated developers.

How to use it:

• Make this template available everywhere people report bugs
• Encourage reporters to fill in as many fields as possible
• If something is missing, use the Intake Checklist to ask for it nicely
• Consider adding this to your GitHub issues, support tickets, or feedback forms

# Bug Report

**Title:** {{Concise summary}}

**Description**
What happened? Include any error messages or observations.

**Steps to Reproduce**
1) {{Step 1}}
2) {{Step 2}}
3) {{Step 3}}

**Expected Result**
{{What should happen}}

**Actual Result**
{{What actually happens}}

**Environment**
- App/Service Version: {{e.g., v1.2.3, build SHA}}
- OS/Device: {{e.g., iOS 17.4 on iPhone 13 / Windows 11}}
- Browser: {{e.g., Chrome 126 / Safari 17}}
- Network/Region: {{if relevant}}

**Severity:** {{Critical | High | Medium | Low}}
**Customer Impact:** {{% users, # reports, key account?}}
**Business Criticality:** {{payments, onboarding, SLAs, compliance}}
**Component/Area:** {{auth, billing, mobile, etc.}}

**Artifacts**
- Screenshot(s): {{link(s)}}
- Screen recording: {{link}}
- Console/Logs: {{inline or attachment}}
- HAR/Network trace: {{attachment}}

**Notes / Workarounds**
{{Any mitigation steps}}

**Reporter:** {{Name/Role}}
**Date/Time:** {{UTC + local}}
**Related Tickets:** {{IDs}}

Why this matters: This is your decision-making compass. Without a clear prioritization framework, every bug feels urgent and important decisions get mired in endless debate. This matrix gives you an objective way to categorize and prioritize bugs consistently.

How to use it:

• Print this out and hang it near your team (or add it to your wiki)
• Use it during triage meetings to quickly assign priorities
• Train your team to suggest priorities when creating bugs
• Review and adjust priorities as business context changes

# Bug Prioritization Matrix (Severity × Impact)

| Impact / Severity | **Critical** (crash, data loss, security) | **Major** (core flow broken) | **Minor** (degraded UX; workaround) | **Trivial** (cosmetic) |
|---|---|---|---|---|
| **High Impact** (most users / core journey) | **P1** – fix immediately | **P1** – fix very soon | **P2** – schedule next sprint | **P3** – low priority |
| **Medium Impact** (subset users / secondary) | **P1** – urgent | **P2** – high | **P3** – normal | **P4** – very low |
| **Low Impact** (edge case / rare) | **P2** – high | **P3** – normal | **P4** – low | **P4** – lowest |

> Calibrate P1/P2 with SLAs below; record rationale in ticket (impact scope, severity, workaround).

Why this matters: This is your institutional memory. Without a clear record of what you decided and why, the same discussions happen over and over again. The decision log creates accountability and prevents endless rehashing of old decisions.

How to use it:

• Keep this in a shared document or your project wiki
• Update it during or immediately after each triage meeting
• Use it to quickly bring new team members up to speed
• Reference it when someone asks “why did we decide that?“

# Triage Decision Log

| Date | Ticket | Summary | Sev | Pri | Decision/Status | Owner | Target | Notes |
|---|---|---|---|---|---|---|---|---|
| 2025-08-22 | #1234 | Login crash on iOS | High | P1 | Accepted – hotfix | A. Kumar | 24h | Affects 18% iOS traffic |
| 2025-08-22 | #1238 | Typo on FAQ | Low | P4 | Deferred – backlog | — | — | Bundle with content sweep |
| 2025-08-22 | #1240 | Avatar upload fails | Medium | P2 | In progress | B. Rao | Sprint-34 | Retry S3 policy |

Why this matters: This is your communication lifeline. Without regular updates, your team and stakeholders lose visibility into what’s happening with bugs. The weekly summary keeps everyone aligned and informed without constant check-ins.

How to use it:

• Send this every Friday afternoon (or whenever your triage meetings happen)
• Share it in your team chat, project updates, or company newsletter
• Use it to celebrate wins and identify concerning trends
• Keep it brief but informative - people are busy!

# Weekly Bug Triage Summary – Week {{YYYY-WW}}

**New Bugs:** {{X}}  |  **Resolved:** {{Y}}  |  **Open:** {{Total}}  (P1: {{n}} / P2: {{n}} / P3: {{n}} / P4: {{n}})

## Highlights
- P1 focus: {{#1234, #1250}} (ETAs {{dates}})
- Trends: {{e.g., spike in Android crashes on 8.1}}

## Notable Changes
- Fixed: #{{id}} – {{one-liner}}
- Closed dup: #{{id}} → #{{canonical}}
- Won't fix: #{{id}} – {{rationale}}

## Backlog Health
- Delta vs last week: {{+/- N}}
- Oldest P2 age: {{N days}} (owner {{name}})

## Next Week Priorities
- {{3-5 bullets}}

*Prepared by {{name}} (Triage Owner)*

Why this matters: Consistent labeling is the secret sauce that makes your triage system actually work. Without good labels, you can’t filter, search, or organize your bugs effectively. This guide helps you create a labeling system that scales with your team.

How to use it:

• Customize this list based on your actual components and platforms
• Add it to your team wiki or project documentation
• Use these labels consistently across all your bug reports
• Review and update quarterly as your product evolves

# Labels & Components – Naming Conventions

**Components:** auth, billing, checkout, dashboard, mobile‑ios, mobile‑android, api, infra.
**Types:** bug, regression, performance, ux, content, security.
**Sources:** customer, internal, monitoring, qa.
**Platforms:** web‑chrome, web‑safari, ios, android, windows, linux, macos.
**States:** needs‑info, ready‑for‑triage, triaged, in‑progress, in‑review, ready‑for‑qa, done.

> Keep labels short; prefer kebab‑case; document ownership per component.

Congratulations! You’ve now got the 7 essential templates to start running effective bug triage. These tools will save you countless hours and help your team make consistent, confident decisions about which bugs to fix first.

Ready to put this into action? Start with the Meeting Agenda and Bug Report Template - those two alone will transform your bug handling process. ⬇️

When to use: When you want to distribute triage responsibility fairly and prevent burnout.

# Triage Owner – Rotation Checklist

**Daily**
- Review new/reopened tickets; run Intake Screening.
- Tag severity/component; page on‑call for Critical.
- Post quick status in #triage (P1 changes).

**Weekly (before meeting)**
- Curate agenda: new items, P1/P2 follow‑ups, small grooming slice.
- Pull metrics: open by priority, age, duplicates, regression count.
- Pre‑read: chase missing info on unclear tickets.

**During meeting**
- Drive decisions: Sev/Pri, owner, target, rationale.
- Capture decisions in tickets + Decision Log.

**After meeting**
- Send Weekly Summary; update roadmap risks.
- Ensure hotfix/RC cut if needed; notify stakeholders.

**Handover**
- Share open P1/P2 list with ETAs, known risks, and contact points.

When to use: When you need quantitative methods to compare and prioritize bugs objectively.

# User‑Pain Score (for ranking)

Rate each 1–5 and compute **Score = Severity × Frequency × AffectedUsers**

- **Severity**: 1 (cosmetic) … 5 (data loss/security)
- **Frequency**: 1 (rare/edge) … 5 (common/often)
- **AffectedUsers**: 1 (<0.5%) … 5 (>50% or key customer)

Sort descending; break ties by strategic impact/revenue risk.

# RICE for Bug Fixes (optional)

**Score = (Reach × Impact × Confidence) / Effort**
- Reach: users per period affected
- Impact: 0.25 (minimal) … 3 (massive) on core metric/UX
- Confidence: 0–1 based on evidence (logs, repro rate)
- Effort: dev days (incl. QA/release)

When to use: When you want to proactively communicate known problems to customers or internal teams.

# Known Issues (Public/Internal)

> Scope & update cadence: {{e.g., updated weekly}}

## Active
- **{{Ticket/Slug}}** – {{short description}}
  *Impact*: {{who/how many}} • *Workaround*: {{steps}} • *ETA*: {{date}} • *Status*: {{in progress/monitoring}}

## Recently Resolved
- **{{Ticket}}** – {{short description}} (Fixed in {{version}}, {{date}})

## Out of Scope / Won't Fix
- **{{Ticket}}** – {{short description}} (Reason: {{rationale}})

When to use: When you need clear rules about who gets notified about what types of bugs and when.

# Bug Notification Policy

- **Critical (P1):** Page on‑call immediately; Slack #incidents; update every 2h until resolved; post‑mortem within 5 business days.
- **High (P2):** Slack #triage + assignee mention; first update within 1 business day; weekly in triage summary.
- **Medium/Low (P3/P4):** Ticket updates only; appear in weekly summary.
- **Customer‑reported (key accounts):** CSM/Support updated within 1 business day with status & ETA.

When to use: When you want to set clear expectations about response and resolution times.

When to use: When you need to regularly clean up and organize your bug backlog to keep it manageable.

# Backlog Grooming – Bugs

- Close tickets with no repro after {{N}} pings & {{M}} weeks (label `stale` before auto‑close).
- Merge duplicates; move unique info to canonical ticket.
- Re‑score User‑Pain for top 20 open; adjust priorities.
- Cull obsolete versions/platforms (label `legacy`).
- Convert feature requests/misfiles to appropriate boards.
- Time‑box grooming to {{30}} minutes per week.

When to use: When you want to encourage quick fixes for trivial issues without the overhead of full ticketing.

# Micro‑Bug Policy (≤15 minutes)

If a bug is trivial (e.g., copy, one‑line CSS/logic) **and** you're in context:
- Fix immediately instead of ticketing; link change to umbrella ticket `micro‑bug‑sweep`.
- Include before/after screenshot; add test if applicable.
- Cap at {{N}} micro‑fixes per dev per week to avoid derailment.

When to use: When you need a clear visual representation of your bug workflow and state transitions.

# Workflow – States & Transitions

`new` → `screening` → `triaged` → `in‑progress` → `in‑review` → `ready‑for‑qa` → `done`
                         ↘ `needs‑info` ↗            ↘ `blocked` ↗

**Entry rules**
- new: created with minimum fields
- screening: intake checklist applied
- triaged: Sev/Pri set, owner assigned, target decided
- in‑progress: branch/PR linked
- in‑review: code review assigned
- ready‑for‑qa: deployed to test; steps to verify included
- done: fixed & verified; release noted; post‑deploy checks passed

**Exit criteria**
- Each transition requires ticket updated with status note and artifacts links.

Quick action items:

1. Pick 2-3 templates to start with this week
2. Customize them for your team’s specific needs
3. Set up your first triage meeting
4. Share the process with your team