BMO/UserGuide/BugStatuses

Bug Statuses

STATUS

The Status field indicates the current state of a bug. Only certain status transitions are allowed.

RESOLUTION

The Resolution field indicates what happened to this bug.

Open Bugs

Statuses

UNCONFIRMED

This bug has recently been added to the database. Nobody has validated that this bug is true. Users who have the "canconfirm" permission set may confirm this bug, changing its state to NEW. Or, it may be directly resolved and marked RESOLVED.

NEW

This bug has recently been added to the assignee's list of bugs and must be processed. Bugs in this state may be accepted, and become ASSIGNED, passed on to someone else, and remain NEW, or resolved and marked RESOLVED.

ASSIGNED

This bug is not yet resolved, but is assigned to the proper person. From here bugs can be given to another person and become NEW, or resolved and become RESOLVED.

REOPENED

This bug was once resolved, but the resolution was deemed incorrect. For example, a WORKSFORME bug is REOPENED when more information shows up and the bug is now reproducible. From here bugs are either marked ASSIGNED or RESOLVED.

Closed Bugs

Statuses

RESOLVED

A resolution has been performed, and it is awaiting verification by QA. From here bugs are either reopened and given some open status, or are verified by QA and marked VERIFIED.

VERIFIED

QA has looked at the bug and the resolution and agrees that the appropriate resolution has been taken. Any zombie bugs who choose to walk the earth again must do so by becoming REOPENED.

Resolutions

FIXED

A fix for this bug is checked into the tree and tested.

INVALID

The problem described is not a bug.

WONTFIX

The problem described is a bug which will never be fixed.

DUPLICATE

The problem is a duplicate of an existing bug (the problems must be exactly the same). Marking a bug duplicate requires the bug# of the duplicating bug and will at least put that bug number in the description field. If a bug has the same root cause as another one but the two bugs are finally different, then they should have a dependency such as depends_on.

WORKSFORME

a) all attempts at reproducing this bug were futile, and reading the code produces no clues as to why the described behavior would occur; or

b) the bug was present once, but is now not reproducible (and so was probably fixed in another bug.)

INCOMPLETE

a) The problem is vaguely described with no steps to reproduce, or is a support request. The reporter should be directed to the product's support page for help diagnosing the issue. If there are only a few comments in the bug, it may be reopened only if the original reporter provides more info, or confirms someone else's steps to reproduce. If the bug is long, when enough info is provided a new bug should be filed and the original bug marked as a duplicate of it. Or:

b) There may have been a valid bug, but we don't have enough information at this point to tell whether the bug is still present or not (e.g. because the only testcase was external-to-Bugzilla and has now disappeared, or because a reproducing testcase was never provided).

MOVED

The problem is now being worked on another issue tracker. The See Also field should contain the URL of the bug on the other tracker.