AbiWord Bug Tracking

If you aren't a computer programmer, you can still help out with AbiWord by helping us keep our Bug tracking system up to date. This sort of work is really helpful to the project, and anyone can join in.

A well maintained bug database means that developers can choose high priority Bugs over low priority ones. In addition, it's VERY helpful when Bugs can be verified to be problems on multiple computers. The more information that can be gathered about a Bug, the better!

Bug Tracking Basics

AbiWord's bug system is called BugZilla. Each of our Bugs can be in one of four states:

UNCONFIRMED

When a Bug is created, its status is "Unconfirmed". Unconfirmed Bugs are good targets, because you can usually add a lot of value to them.

In particular, if the Bug does not contain sufficient information to reproduce or even describe the problem and its symptoms, ask the reporter for more information. Make a note of this request in the Bug (add the 'needinfo' keyword). If no information is added within two weeks, close the Bug, but make sure to noting in the 'Additional Comments' field why it was closed. The Bug Policy page has a list of URLs you can paste in as way of explaining the action if it's a standard reason.

If the Bug is a duplicate of an older Bug, resolve it as a duplicate. If there are good descriptions / information in the newer Bug, post these directly to the older Bug so it's easily accessible. Resolving newer Bugs means we know when the problem was first reported - and it helps us to prioritize properly (the older a Bug gets, the higher its priority should be).

If there is enough information to reproduce the problem, please try to do so, and register in the Bug report whether you have succeeded or not. Remember to include the version (and platform) of AbiWord you used. Then "Confirm" the Bug. This lets developers know that the Bug was confirmed by someone else than the reporter.

NEW and ASSIGNED

If a Bug is NEW, it means it has been classified as a genuine problem with the software which needs to be fixed. Developers accept Bugs in this state when they want to work on them (by changing the status to ASSIGNED).

The severity and priority of all NEW and ASSIGNED Bugs should be monitored and updated as higher priority Bugs get closed by developers and new ones are added from the UNCONFIRMED state.

Bugs that contain feature requests (i.e., not problems with existing AbiWord features), should have their severity changed to Enhancement - and be prioritized accordingly. They should also have the 'rfe' keyword added.

Developers assign themselves to work on Bugs while they are in the NEW or ASSIGNED state. When the problem has been fixed, they will move the bug to the RESOLVED state.

RESOLVED

The developer has checked in a fix for the problem described in the Bug. Someone else, preferably the reporter, must rebuild the latest sources (or get a nightly build or wait for the next official release) and check that the problem has indeed been fixed.

When moving a Bug from this state to the VERIFIED state, remember to set the resolution correctly:

FIXED

A fix for this Bug has been checked into the tree, and it has been independently tested that it did fix the problem.

INVALID

The problem described is not a bug, information is missing, or the information in the Bug is obsolete and needs updating to make the Bug relevant again. Just close any INVALID Bugs you happen to see - they are only in the RESOLVED state because there's no direct route to the VERIFIED state.

WONTFIX

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

REMIND and LATER

Avoid these states. Use the Bug's Milestone field to communicate expected completion of the Bug.

WORKSFORME

All attempts at reproducing this Bug were futile, reading the code produces no clues as to why this behavior would occur. If more information appears later, please reopen the bug, for now, it should be moved to the VERIFIED state.

VERIFIED

Make sure that you only move Bugs to the VERIFIED state which were initially reported against the same architecture you are using - or if someone had successfully reproduced the Bug on your architecture. We don't want to close Bugs for architecture X just because they cannot be reproduced on architecture Y.

This is the final state of a Bug.

Severity and Priority

The severity of a bug describes how much of a problem it is.

Critical

Crash, data loss, severe memory leaks...

Major

Major loss of function

Minor

Minor loss of function, or other problem with an easy workaround.

Trivial

Cosmetic problem (misspelled word, misaligned text, ...)

Enhancement

Request for enhancement

Alternately, the priority of a Bug describes importance, and order that Bugs should be fixed in. The highest priority is P1, and the lowest is P5. Priority is determined by combining severity (above) with frequency of the problem.

For example, a severe but rare Bug might be given P3 priority, whereas a Bug that is Minor but occurs very often might have P2 or P1.

Becoming a Bug Tracker

All you need to do to become a Bug tracker is go over to bugzilla.abisource.com and create yourself an account. Once you've got your account, you can help us to your heart's content, and we'll really appreciate it!