Subject: Dealing with AbiWord bugs
From: Jesper Skov (jskov@redhat.com)
Date: Wed Feb 21 2001 - 11:11:13 CST
AbiWord Bugs
~~~~~~~~~~~~
AbiWord bugs can be in one of five states (A Bug's Life Cycle). Have a
look at the query page http://www.abisource.com/bugzilla/query.cgi
while you read the below (and bookmark
http://www.abisource.com/bugzilla/bug_status.html which contains the
same information).
o SUBMITTED
This is the state a newly created bug ends up in. It means it has
been registered in the system, but it has not been triaged yet (see
Triaging Bugs below).
o OPEN
When a bug is in the open state 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 Assigned To field).
o QA TO VERIFY
When a developer believe s/he has fixed the problem described in
the Bug, the bug's state is changed to QA to verify. It means that
the developer requests others to check if the fix also works for
them.
The reason this state is called QA to verify is that having more
than one person check the fix improved the overall quality of the
product - QA means Quality Assurance. The fix provided by the
developer may only be partial, or it could depend on other changes
in his/her tree. Therefore having others test a fix before the Bug
report is closed makes a lot of sense - even if it adds a layer of
bureaucracy.
o POSTPONED
This category should probably be removed.
It has served as a bucket for reminders in the past - but judging
by the Bugs in this category, they tend to be forgotten.
o CLOSED
When a bug has been fixed (or discarded) it gets closed. The
information is still kept in the bug database though - and the bug
may be reopened if necessary later.
Bug Severity & Priority
~~~~~~~~~~~~~~~~~~~~~~~
Bugs have two properties used for prioritizing its location in the Bug
queue:
Severity describes the impact of the Bug:
Critical Crashes, loss of data, severe memory leak
Major Major loss of function
Minor Minor loss of function, or other problem where easy
workaround is present
Trivial Cosmetic problem like misspelt words or misaligned text
Enhancement Request for enhancement
Priority describes the importance of the Bug:
URGENT Most important
HIGH
MEDIUM
LOW
TRIVIAL Least important
Priority is determine by combining impact and frequency. So, a medium
bug may be one that is severe and rare, or it could be one that is
common and of minor annoyance.
Triaging Bugs
~~~~~~~~~~~~~
Triaging is the process of pushing Bugs through their life cycle as
well as reprioritizing Bugs according to user reports and as a result
of Bugs being closed by developers.
It is important to understand that all developers (like yourself) work
on AbiWord in their spare time and are entirely free to decide which
problems to look at.
However, there's a good chance that a well maintained bug database
will cause developers to select high priority Bugs more often than low
priority Bugs.
So the goal - and the hard part of triaging - is to keep all the bugs
well prioritized. That means that most Bugs should have a Medium-Low
priority, a much smaller number should be High priority, and only a
few should have Urgent priority. If there are too many High/Urgent
priority Bugs, there is no idea in prioritizing the Bugs.
These are the triaging actions for the Bug states:
SUBMITTED
If the Bug does not contain sufficient information to reproduce or
even describe the bug and its symptoms, ask the reporter for more
information. Make a note of this request in the bug. If no
information is added within a week, close the bug, but make sure to
notify the reporter that it has been closed and why.
If the Bug is a duplicate of an older Bug, close 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. Closing
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 bug, 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. Move the Bug to the OPEN state.
OPEN
The severity and priority of all OPEN Bugs should be monitored and
updated as higher priority Bugs get closed by developers and new
ones are added from the SUBMITTED 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.
Developers assign themselves to work on Bugs while they are in the
OPEN state. When done they will move the Bug to the QA TO VERIFY
state.
QA TO VERIFY
The developer has checked in a fix for the problem described in the
Bug. Someone must rebuild the latest sources and check that the
problem has indeed been fixed.
When moving a bug to this state, remember to set the resolution
correctly:
FIXED
A fix for this bug is checked into the tree.
INVALID
The problem described is not a bug
WONTFIX
The problem described is a bug which will never be fixed.
REMIND
The problem described is a bug 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 bug. Marking a
bug duplicate requires the bug# of the duplicating bug and
will at least put that bug number in the description
field.
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 re-assign
the bug, for now, file it.
OBSCURED
The bug wasn't fixed, but the method of revealing it has
been removed. This can occasionally happen when a GUI is
reworked, or when functionality is altered.
Bugday
~~~~~~
Bugday is when people interested in AbiWord meet on IRC (channel
#abiword on irc.gnome.org) to work in concert on triaging the Bugs.
The bugday coordinator (nick prefixed with _) will try to help direct
people to various Bugs (or ranges of Bugs) to prevent people from
stepping on each others toes.
It's pretty informal though, so don't expect too much :)
Be helpful
~~~~~~~~~~
Be polite and informative if closing a bug report. We want to
encourage people to keep filing _good_ bug reports. They will stop
doing that if they feel their effort is not appreciated.
If you do not feel confident dealing with a particular bug report,
skip it. We do not want to just close bugs for the sake of getting a
low bug count!
Cheers,
Jesper
This archive was generated by hypermail 2b25 : Wed Feb 21 2001 - 11:11:29 CST