Error Tracker Workflow

Normal workflow for dealing with an error

1. An error is reported. Its state is NEW.

• All bugs in the state NEW should be considered as not being worked on, even if there is a conversation going on in comments. Any indexer should feel free to start working on them by performing the next step:

2. An indexer decides to work on the error. The indexer goes to the error page and scrolls down to the radio button section at the end and selects "Accept bug (ASSIGN error to yourself)", optionally adds comments, and clicks "Update". This sets the state to "ASSIGNED".

• All bugs in the ASSIGNED state are being worked on. No one but the assignee should work on them without first contacting the assignee.

3. Once the necessary changes are made, reviewed and approved, the indexer goes back to the error page and again scrolls down to the radio buttons. This time the indexer selects "Resolve error, setting resolution to: ..." and leaves the default FIXED resolution in the drop-down menu. The indexer may optionally also add comments, and then clicks "Update". This sets the state to RESOLVED.

• RESOLVED errors no longer appear in the list of open errors. They can be searched by using the advanced search screen.

Other resolutions for dealing with an error

Sometimes we'll get errors that should not or cannot be fixed. These are given other resolutions, typically without ever being in the ASSIGNED state since there is no work to be done.

• If the same error is reported twice, select the "Mark error as duplicate of error #..." and put the other error's number in the box. Typically, one marks the newer error as a duplicate of the older, but if the newer error report contains more detail, you might mark the older one as duplicate instead. This is most likely to happen with error reports for which we don't have enough information to fix, and which will therefore stay open for a long time.

• If we believe that the error report is simply wrong, select "Resolve error, setting resolution to: ..." and select "NOT ERROR" from the list of resolutions. While Bugzilla won't force you to do so, you should include a comment explaining why the report is believed to not be an error as a courtesy to the submitter. Note that it's a good idea to file an error report and mark it as a non-error yourself if you find a common misconception surfacing over and over again. That way we'll have it documented for the next time around.

• If something can't be fixed in the current site / schema, you can use the resolution "NEW SITE". We'll go back over these when we update the code on the website and see if they can be fixed properly then.

Post-RESOLVED options

Once an error is resolved, some new radio button options appear. "Mark as CLOSED" will move the error to a closed state. "REOPEN error"

Unless someone reopens the error (possibly the submitter if they are unhappy with the resolution, or another indexer if they think something was missed or done incorrectly), a RESOLVED error is essentially the end state. Traditionally, there are two other states- VERIFIED (which I have disabled) and CLOSED (which I have left present). The way things are set up now, I view CLOSED as indicating that the resolution has been accepted. Traditionally, the submitter would set this state, although probably that won't happen most of the time for us. We can just either close errors in bulk periodically, or just ignore the state.