We based this on a two database model:"projects" and "issues".
The work flow is different for each one. It seems that the compiler Bugzilla database is closer to his "issues" database. We are striving for ease of use. We have thus combined some original attributes and deleted others.
When To Open a Ticket
A bug or task should be able to be completed. Please be specific and note exactly how resolution is tested.
Something like "The backend needs to be tested" in itself is not sufficient. How does it need to be tested, on what does it need to be tested, when is it tested enough?
If one wants a generic task that points to a series of specific tasks, please mark its TYPE as TRACKING. This allows for some structure without saddling the assignee to a "bug for life" that shows up at every bug blitz.
How the ticket is used for searching and filtering.
|BUG:||Something broken in the product|
|TRACKING:||Place-holder or long-term project usually blocked by other tickets|
|FEATURE:||Something new that the product does not currently have or do|
|ENHANCEMENT:||An improvement to an existing element of the product|
|INQUIRY:||Somebody asking a question|
The current status of the ticket
|OPEN:||Bug submitted; probably assigned to default owner. A bug only returns to this state if it needs a new engineer assigned to it and it's unclear to the current owner who that would be.|
|ASSIGNED:||Sent to the appropriate person.|
|CONFIRMED:||The bug has been triaged and will be worked on soon.|
|IN PROCESS:||Work has started and is continuing on the bug. This includes code in review.|
|BLOCKED:||Work is not finished on the bug, but it is blocked for some reason like lack of test case or resources.|
|IN SUBMITTAL:||Waiting for fix to be accepted into the main repository|
|RESOLVED:||Work committed and declared done by owner|
|CLOSED:||The bug has been verified fixed|
- A person managing a bug can change the status to any of the other states.
- When something gets finalized (CLOSED) we need to link back to the final acceptance. For LLVM that could be the revision number of the commit to trunk. There will be a text box where the revision number or URL can be written or pointed to.
The RESOLVED state will in addition have one of the following resolutions:
|FIXED:||The assigned engineer thinks the bug is fixed and needs outside verification.|
|INVALID:||The premise for this bug is in error.|
|WONTFIX:||Can't be fixed right now.|
|DUPLICATE:||Same as another another bug. The duplicate bug number is required.|
|INSUFFICIENT INFO:||The submitter was either too vague or lacked a test case. Unreproducible cases are also resolved to this state.|
When setting something as RESOLVED and there is a link a commit or some other acceptance record, add the information in the Resolution References text box.
SEVERITY and PRIORITY
Severity describes the impact the bug has on the reporter. Priority describes how quickly the bug needs to be resolved. Here are 2 extreme examples illustrating the use of the 2 attributes:
- There is a bug in the OS that will cause it to crash and burn, but it is with a remote corner case that will almost never get hit and it is difficult to fix. S1/P4
- There is a small typo in the Copyright, Imps instead of Mips. It is really easy to fix, but is a big deal legally. S4/P1
|S1:||The product crashes or doesn't work for customer|
|S2:||The product is highly degraded for customer|
|S3:||Normal, most bugs should fall here|
|S4:||The customer isn't concerned about this bug|
Hopefully having enumerated severities will take some of the emotion out of it
|P1:||Most important bug. There will usually be only one P1 bug. The bug the engineer is focusing on unless it's blocked.|
|P2:||Next most important bugs.|
|P3:||Most bugs will be P3.|
|P4:||Least important bugs.|
Sometimes an engineer wants to have a different hierarchy for their bugs. This should be done with Tracking nodes. To make a Tracking node, a bug is created with the TYPE TRACKING and marked RESOLVED to avoid it showing up in management's bug lists. The type of resolution is up to the user. Then, any bugs that relate to this Tracking node, block it. One Tracking node can block other Tracking nodes, but an individual work item should only block a Tracking node never depend on a it.
Here is a picture of tasks that are connected to both a Tracking node on the left and a project goal on the right. The Tracking nodes are gray. The project goals are multicolored. The work items are white.
On the left is the engineer's hierarchy with 2 levels of TRACKING nodes. On the right are the release bugs. The release manager will be mostly interested in what is in this release whereas the engineer and/or engineering manager may want to know the full project layout regardless of which release they are a part of or even if the bug has been already closed.