Reporting Bugs

If you happen to find a bug in AbiWord, please report it using the AbiWord’s Bugzilla (bugzilla.abisource.com). It is quite possible that the project developers don’t know about a specific problem, so by filing a well-written report anybody can have input on future versions of AbiWord.

These notes should help you create a bug report that will prove useful to the developers.

Overview: Bugzilla

Things to Check

Create a New Account with Bugzilla

New Bugs

Creating a Useful Bug Report

Things to Check

Make sure that you are using the most recent version of AbiWord. If not, update and try again. If you report a bug from an old version the developers will probably ask you to update and try again. Many changes are made between versions.

Next, check to see whether your bug has already been reported. Go to the Bugzilla main page (bugzilla.abisource.com) and type a word in the search box that anyone reporting your bug would be very likely to use, but which won’t turn up too many bugs.

If your bug has already been reported and hasn’t been fixed, then you can vote for it if you have an account with Bugzilla (see next section). Click on the vote link on the bug page and add a number of votes.

Create a New Account with Bugzilla

The first thing to do for a new bug or feature request is to create an account on AbiWord Bugzilla. Go to bugzilla.abisource.com/createaccount.cgi and follow the instructions.

Bugzilla will require a valid email address. A developer may need to ask for more information on the exact nature of the bug or feature request if a report you have filed is unclear, or you may receive a simple email update on it’s progress. This is all that your email address is used for.

Next, check your inbox for a password from Bugzilla. You will need it to log into your Bugzilla account.

New Bugs

If your bug is new, click on the “Enter a New Bug” link. If you aren’t already logged in to Bugzilla, you will be asked to supply your email address and the password that was mailed after the account was created.

Now decide whether you have a bug or a feature request. A bug is something that AbiWord does wrong; a feature request is something that it doesn’t do which you would like it to. For example, if the program crashes when you try to open a document, that’s a bug. If you need AbiWord to support tables, then that’s a feature request. If your report concerns a feature request, put [RFE] at the beginning of the summary line. (RFE stands for Request For Enhancement.) Otherwise for standard bug reports, leave this off.

Creating a Useful Bug Report

Above all else, a useful bug report will be both reproducible and specific. Please include any specific details you can think of to help somebody else reproduce the bug. Create a list of steps in the “Description” box. If you’re not sure how to repeat it, please still be as specific as possible. Also include the version of AbiWord with the bug in the “Description” box.

Be sure to set the “Platform” and “OS” menus to match your computer. The platform information is mainly important for OSes like Linux, which can run on diverse of kinds of hardware, but it is nonetheless an important option.

The next stage is to summarize your bug. Make this a short sentence which is specific and descriptive. If the bug crashes AbiWord (that is, makes the program quit or freeze), put [crash] at the beginning. If it’s a feature request, put [RFE] (for Request For Enhancement) at the beginning.

Good summaries:

[crash] AbiWord crashes when opening this document

[RFE] Table editor

[crash] Crash when undoing paste

Bad Summaries:

Bug in AbiWord

File’s broken

You all suck

Now decide how serious your bug is. If it’s a feature request, the severity is “enhancement”. Developers like doing cool new features so this doesn’t put the request at the back of the queue. A crash is always at least major -- if not critical. Nothing other than a crash is critical. If the bug breaks an important function, it is major. Anything that is easy to work around is minor or trivial.

You should also decide the priority of the bug. Be reasonable. Developers will reset overly high low priorities. “P1" is the highest priority and should only be set for very important bugs.

If your bug only occurs with a particular file, the file can be attached using the web page once you have submitted the bug report. If you can reproduce the bug in a new document with a small amount of typing, give step by step instructions. Again, these must be clear enough for the developers to follow or the bug will be marked invalid and closed.

Good Descriptions:

Opening the attached file crashes AbiWord. [attachment]

I’d really like to be able to do tables in AbiWord.

Open a new file. Type a few words. Select all, and copy. Paste. Undo. Boom.

Bad Descriptions:

AbiWord can’t open some Word files.

My file doesn’t look like it should when I reopen it.

AbiWord MUST HAVE TABLES. Add tables now, or I will scream and scream until I’m sick. If you don’t do tables NOW, you suck worse than Microsoft.

Press the “Commit” button to add your bug to the database. New bugs are added in “Submitted” state. Someone will later check that they can reproduce the bug and change it’s status to “Open”.