| It's odd to me that the proposed Minimal Skeleton for tracking a bug doesn't include: * who reported the issue
* what they reported happening
* what they expected to happen instead For many reported bugs, it is clear what the actual problem is and what needs to be done to resolve it. In this case, it can feel like unnecessary overhead to track the bug in a separate system from the rest of the development work queue. But it's worthwhile to have a place to track bug reports that can't yet be acted on by writing code. Sometimes it's not immediately clear what is happening or what should be done about it. Sometimes you need to reach out to the reporter(s) for more information or to let them know progress has been made. Even with well-understood bugs, there can be a many-to-many relationship between the bug and the development work to be done. Sometimes you have many people reporting the same issue in different ways, and it's not initially clear that there's a shared root cause. Sometimes one bug report is best addressed in multiple phases of development work. I'd argue that there's always someone who's managing all of the above, even if they're not using separate bug tracking software to formally do so. But as a team grows, making the investment to "show your work" a little more can make it a lot easier to collaborate and delegate. |
* I am not sure "who reported the issue" is actually important, but rather "who is the contact person to get more information about this issue" and "who should be informed when this is done for verification", where "verification" means "satisfies expectations now" (as opposed to QA meaning of the word)
* Reported happening/expectation is a good point for any expectation mismatch report. I am not sure it should be there for all issues though as I find it can decrease clarity in the same way artificially requiring the "As X, I need to do Y in order to achieve Z" does