Questions You Can't Answer
Urgent? Write the responsible individual directly via email or chat. Ex.: Question about a card pre-release? Talk to the dev directly.
Non-Urgent (like Product Review buckets)? Send an email to pm@ and if an answer is not received in 3 business days or more, follow up again.
Feature Tweaks
Small tweaks that can be written up as a feature card need ownership. If it needs User Acceptance Testing, that needs to be run by Small Council. Anything else is either Design or Engineering.
- If Design, assign to Adela (assuming it can't just go on Design Tweaks card)
- If UAT is needed, assign to Paul W
- If it's Engineering specific, assign to Joel / Chris
Applying Hotfix Labels in GitHub
Is this a critical issue that must be fixed immediately?
├─ YES → Apply `should-hotfix`, route to Sysops
└─ NO → Is the fix already complete and straightforward?
├─ YES → Consider `fastlane-hotfix` for T3
└─ NO → Route to DPAF/T3 with suggestion for hotfix consideration
Fastlane should go to DPAF/T3 for review and Product should suggest a hotfix, but leave that to the devs to determine in the end when creating the card.
Bug Management & Hotfix Process
Question: Should all proposed bug cards go through bug hunt?
Answer: No - there are two paths depending on the bug's scope and risk:
Standard Path (Bug Hunt → Assign → Testing → Deploy)
- Use for complex issues
- Use for bugs with potential unexpected consequences
- Use for long-running or widespread problems
- Timeline: ~1 month
Hotfix Path (Quick Fix)
- Who: T3/T4/OnCall teams are encouraged to use this path
- When appropriate for:
- Small, isolated issues
- Clearly wrong behavior with obvious fixes
- Low-risk changes (e.g., sort order on a grid, minor UI issues)
- Process:
- T3/T4/OnCall identifies suitable bug
- Fix implemented and self-validated
- Hotfix deployed
- Product reviews and tests after deployment
- Follow-up tweaks made if needed
Key Principle: Avoid hotfixing anything that could have unexpected consequences or affects multiple areas of the system.