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
