--- tags: development process, wip --- # [WIP] Bug Handling Process Handling bugs and supporting out customers is a big part of our work. In this document I would like to propose a repeatable bug handling process. ### Goals 1. Reduce the amount of time risk associated with a bug 2. Have clearly defined steps to work the bug and provide status to the stakeholders 3. Increase the probability that our (re)solutions are the right ones 4. Don't lose track of back ports 5. Don't lose track of customer feedback (e.g. answers to follow-up questions, requesting must-gather, etc.) ### Process 1. Triage bug: Is it a bug? Do we want to fix it? What's the priority? Do we have enough information to continue? 2. Time-box investigation/repro: during refinement, estimate the time box necessary to investigate the bug: "How much time do we want to spend on this bug before we make the decision to put more resources on it?". We should agree on a maximum, e.g. 1 weeks. After which we re-asses with the information we have gathered. The output of this step should be clear instructions on how to reproduce the bug (a script is always best) and a clear understanding of what is wrong to the point where we can break it down, OR require a design task to follow-up. 3. (Optional) For exceptionally large/hairy/complex bugs, schedule it for a design round (see [Design Process](https://hackmd.io/Bfbe6WyeQY2L9Jjhl2RtPA)) 4. Split the work into stories and queue them up for refinement 5. Tee up the refined stories the next sprint.