1.7Real-World Scenarios

Scenario 1: The Recurring Bug

You have filed the same type of bug three sprints in a row -- input validation missing on new forms.

Bad approach: Filing another bug with a passive-aggressive note: "Same issue as SHOP-456 and SHOP-512. Please check other forms too."

Good approach: File the bug normally. Then, separately, propose a solution: "I have noticed input validation gaps on three consecutive sprints. Could we add a shared validation component or a checklist item in our PR template? Happy to help draft it."

Scenario 2: The Friday Afternoon Critical Bug

You find a critical bug at 4:30 PM on Friday in a feature shipping Monday.

Bad approach: Filing a P0 bug and going home, leaving the developer to discover it Monday morning with no context.

Good approach: File the bug. Send a direct message: "Hey, I found something critical in the checkout flow that blocks Monday's release. I filed SHOP-789 with full details. I know it is late on Friday -- let me know if you want to look at it now or first thing Monday, and I can adjust the release plan either way."

Scenario 3: The Bug You Are Not Sure About

The application behaves in a way that seems wrong to you, but you are not 100% sure it is a bug.

Bad approach: Filing a bug with "I think this might be wrong?"

Good approach: Frame it as a question: "Observation: When a user has both a percentage discount and a fixed discount, the percentage is applied first. Is this the intended order of operations? If so, we should document it. If not, the calculation in the checkout service may need adjustment."