An Issue's Life Cycle

Status

The status field indicates the general health of an issue. Only certain status transitions are allowed. The resolution field indicates what happened to this issue.

Open State issues: The following status values are in an "open" state; they have no resolution.

• UNCONFIRMED: This issue has recently been added to the database. Nobody has validated that this issue is true. Users who have the "canconfirm" permission set may confirm this issue, changing its state to NEW. Or, it may be directly resolved and marked RESOLVED.
• NEW: This issue has recently been added to the assignee's list of issues and must be processed. Issues in this state may be accepted, and become STARTED, passed on to someone else, and remain NEW, or resolved and marked RESOLVED.
• STARTED: This issue is not yet resolved, but is assigned to the proper person. From here issues can be given to another person and become NEW, or resolved and become RESOLVED.
• REOPENED: This issue was once resolved, but the resolution was deemed incorrect. For example, a WORKSFORME issue is REOPENED when more information shows up and the issue is now reproducible. From here issues are either marked STARTED or RESOLVED.

Resolved State issues: The following status values are in an "resolved" state; they have no resolution.

• RESOLVED: A resolution has been taken, and it is awaiting verification by QA. From here issues are either re-opened and become REOPENED, are marked VERIFIED, or are closed for good and marked CLOSED.
• VERIFIED: QA has looked at the issue and the resolution and agrees that the appropriate resolution has been taken. Issues remain in this state until the product they were reported against is actually released, at which point they become CLOSED.
• CLOSED: The issue is considered dead, the resolution is correct. Any zombie issues who choose to walk the earth again must do so by becoming REOPENED.

NOTE: Resolved state issues can have the following resolution values:

• FIXED: A fix for this issue is checked into the source code repository and tested.
• INVALID: The problem described is not an issue
• WONTFIX: The problem described is an issue which will never be fixed.
• LATER: The problem described is an issue which will not be fixed in this version of the product.
• REMIND: The problem described is an issue which will probably not be fixed in this version of the product, but might still be.
• DUPLICATE: The problem is a duplicate of an existing issue. Marking an issue duplicate requires the issue number of the duplicating issue and will at least put that issue number in the description field.
• WORKSFORME: All attempts at reproducing this issue were futile, reading the code produces no clues as to why this behavior would occur. If more information appears later, please re-assign the issue, for now, file it.

More about the sequence of an issue's status

What happens to an issue when it is first reported depends on who reported it. By default, issues reported (that is, entered) into IssueZilla are assigned a status of UNCONFIRMED. This means that a QA (Quality Assurance) person -- or whoever has the appropriate permissions on your project -- needs to confirm that this issue is legitimate before changing its status to NEW. By sending mail to issues-subscribe@<projectname>.domain.com, you can be notified of all changes to an issue. You then use issue tracking to view and further "workflow" the issue.

If you are a project member who is a developer/user/tester, you can create NEW issues and assign them to other developers. When an issue's status becomes NEW, the developer assigned the issue either accepts it or reassigns it to someone else. If the issue remains new and inactive for more than a week, IssueZilla nags the issue's owner with email until action is taken. Whenever a issue is reassigned or has its component changed, its status is set back to NEW. The NEW status means that the issue is newly added to a particular developer's plate, not that the issue is newly reported. Think of NEW as an important e-mail you need to answer, except you respond through IssueZilla, and you can use this tool to track the issue's progress more efficiently than e-mail.

Some project members with additional permissions have the ability to change all the fields of a issue. (Default permissions only allow limited fields to be changed. (Read more about IssueZilla permissions). Whenever you change a field in a issue it's a good idea to add additional comments to explain what you are doing and why. Make a note in the comments field whenever you:

• change the component
• reassign the issue
• create an attachment
• add a dependency, or
• add someone to the CC list.

Whenever someone else makes a change to an issue or adds a comment, they are added to the CC list and the owner, reporter, and CC list receive an email announcing changes to the issue. This email reports the change using a "diff" format, marking which lines have changed and including any new comments.

Verifying issues

When issues are marked resolved, project/component owners look at these to make sure the appropriate action has been taken. If they agree, the issue is marked VERIFIED. Issues remain in this state until the product or version is released, then the issue is marked CLOSED. Issues may come back to life by becoming REOPENED.

Be careful about changing the status of someone else's issues. Instead of making the change yourself, it's usually best to make a note of your proposed change as a comment first and to let the issue's owner review this and make the change themselves. For example, if you think one issue is a duplicate of another, make a note of it in the "Additional Comments" section of the issue.

If you make a lot of useful comments to others' issues, you gain their trust in your judgement and you may be given permissions to go ahead and make the changes yourself. Unless and until this happens, exercise discretion by using the "Additional Comments" section.