Bug Handling Process (CQ)¶
Owner: Vi | Updated: 2026-02-05
Purpose¶
Handle bugs quickly without overthinking. Small bugs get fixed immediately. Big bugs get triaged properly.
Erik's philosophy: If you can fix it in under 30 minutes, just fix it. Don't think too hard.
Two Types of Bugs¶
QA Bugs (Internal) - Found by QA or internal team before production - Caught during Beta or Final testing - Logged in ClickUp, linked to feature task
Production Bugs (External) - Found by Erik, clients, or users in production - Posted in #cq-product immediately - Needs fast response
The 30-Minute Rule¶
If you can fix the bug in under 30 minutes, just fix it. Don't wait for triage. Don't create elaborate tickets. Don't schedule meetings.
See it. Fix it. Ship it. Move on.
Severity Levels¶
Critical — Drop everything - Production is broken - Users cannot use core functionality - Data loss or security issue - Fix immediately, all hands if needed
High — Fix today - Feature doesn't work as expected - Workaround exists but painful - Affects multiple users - Fix same day, don't wait
Medium — Fix this week - Minor functionality issue - Edge case fails - UI/UX problem but usable - Schedule into current work
Low — Fix when convenient - Cosmetic issues - Rare edge cases - Nice-to-have improvements - Add to backlog, fix during downtime
Who Fixes the Bug?¶
Default: The person who built the feature.
Exception: If you see it and can fix it in under 30 minutes, just fix it. Don't wait for the "owner."
If you can't fix it: Post in #cq-product with context. Tag the feature owner or Vi.
Bug Handling Flow¶
QA Bug (Internal)¶
QA finds bug
↓
Log in ClickUp (link to feature task)
↓
Dev fixes during current phase
↓
QA verifies fix
↓
Done
Production Bug (External)¶
Erik/client reports bug in #cq-product
↓
First dev who sees it: Can you fix in 30 min?
↓
YES → Fix it, deploy, confirm in channel
NO → Tag feature owner or Vi, add severity
↓
Triage if needed (Critical/High = now, Medium/Low = schedule)
↓
Fix → Deploy → Confirm in #cq-product
Posting a Bug¶
When you find or receive a bug, post in #cq-product:
**Bug:** [What's broken]
**Severity:** Critical / High / Medium / Low
**Steps to reproduce:** [How to see the bug]
**Expected:** [What should happen]
**Actual:** [What happens instead]
**Screenshot/video:** [If helpful]
Example¶
**Bug:** Payment button doesn't respond on mobile
**Severity:** High
**Steps:** Go to checkout on iPhone, tap "Pay Now"
**Expected:** Payment modal opens
**Actual:** Nothing happens, no error
**Screenshot:** [attached]
Responding to a Bug Report¶
If you can fix it (<30 min):
Got it. Fixing now.
Fixed and deployed. Can you verify? [link]
If you can't fix it:
Can't fix quickly—looks like [brief diagnosis]. @[owner] can you take this?
If you need more info:
Need more context: [specific question]. Can you share [screenshot/steps/etc]?
Bugs During Feature Development¶
If QA finds bugs during Beta or Final:
- Dev owns fixing them (part of the phase)
- Don't mark phase complete until bugs resolved
- Critical bugs = stop and fix
- Medium/Low bugs = fix before moving to next phase
Bug vs Feature Request¶
Sometimes what looks like a bug is actually a feature request.
Bug: "The search doesn't return results" (it should work) Feature: "The search should support fuzzy matching" (it doesn't today)
If it's a feature request disguised as a bug, clarify:
This is working as designed. If we want [new behavior], that's a feature request.
Should I create a task for it?
After Fixing¶
- Confirm fix in #cq-product thread
- If it was a QA bug, mark resolved in ClickUp
- If same bug keeps happening, note it—might need deeper fix
FAQ¶
Q: What if I'm in the middle of a feature and a Critical bug comes in? A: Drop the feature. Fix the Critical bug first. Then return to your feature.
Q: What if I don't know how to fix it? A: Post what you found. "I looked at X, seems like Y might be the issue, but I'm not sure. @[someone] can you help?"
Q: Should I write tests after fixing a bug? A: For Critical/High bugs, yes—prevent regression. For Low bugs, use judgment.
Q: What if Erik reports something that isn't actually a bug? A: Respond respectfully: "I checked and this is working as designed because [reason]. Should we change the behavior?"
Summary¶
See bug → Can fix in 30 min? → Just fix it. Can't fix quickly? → Post context, tag owner, triage by severity. Critical = drop everything. High = today. Medium = this week. Low = backlog.
Don't overthink. Fix fast. Ship.