Tentative Bug Solution Categories
So here's a quick breakdown of some obvious categories (names will probably need some work) that come to my mind looking at the bugs. I've tried to prioritize action items that are realistic and will minimize the chances of a bug disappearing. My personal feeling is that there should be a base-line accountability to the group when a bug is assigned (by consensus/volunteering) so that any Open bugs belonging to that person are reported on approximately weekly until they're solved.
Category Name |
Explanation |
Action Item |
---|---|---|
Urgent |
Anything with 'Blocker' priority |
Ensure that someone is actively working this issue. If not, assign one or more members of the team to work it. Schedule a team programming break-out session to happen asap. |
Difficult (Coding) |
Bug that has been attempted by someone but without finding a complete solution |
Schedule team programming or determine if another member of the team has a better chance of solving |
Obvious (Coding) |
Looks like there's a straightforward solution. Generally these will either not yet have been addressed or the obvious answer didn't come to the person who first attempted to solve it. |
These are good ones for a quick discussion (2 mins or less). By the end of that discussion someone should volunteer to follow up and report back on progress by the next meeting. Some substantial percentage of the bugs should fall into this category. |
Unclear |
These bugs are not ones that can reasonably be solved given the information at hand. |
We need some push back on these initially - we should try to keep these to a minimum, since it's too easy to throw bugs back and have them get trapped in a wait state while the other person or group is supposed to be responding. We shouldn't place bugs in this category unless one of the developers has made a reasonable effort already to figure out the information from context. Potentially these may get re-assigned to QA for follow up. Developers shouldn't waste more than fifteen minutes going down a rabbit hole for information. |
Pass |
May require outside help from another team or may not be a programming task. |
Assign someone from the group to communicate this information to the relevant party and follow the bug in JIRA until it can reasonably be passed off to someone who can manage it directly in JIRA. Need to ensure that we don't lose bugs this way. |