Someone with WWW CVS access please add the below file as dev_bugs.phtml and add it to the list of developer links. We should also update http://bugzilla.abisource.com/bugwritinghelp.html to something more relevant. Any takers? Thanks, Jesper <? include ("shared.inc"); ?> <HTML><HEAD><TITLE>AbiSource Bugs</TITLE> </HEAD> <? show_body_tag(); user_sidebar ($REQUEST_URI,"Developer"); ?> </TD> <td valign = "top"> <h2>AbiWord Bugs</h2> <p> 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). </p> <dl> <dt><p>SUBMITTED</p></dt> <dd><p>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 <a href="#triage">triaged</a> yet.</p> </dd> <dt><p>OPEN</p></dt> <dd><p>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 <tt>Assigned To</tt> field). </p> </dd> <dt><p>QA TO VERIFY</p></dt> <dd><p>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.</p> <p>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.</p> </dd> <dt><p>CLOSED</p></dt> <dd><p>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.</p> </dd> </dl> <h3>Bug Severity & Priority</h3> <p>Bugs have two properties used for prioritizing its location in the bug queue:</p> <p>Severity describes the impact of the bug:</p> <dl> <dt><p><tt>Critical</tt></p></dt> <dd><p>Crashes, loss of data, severe memory leak</p></dd> <dt><p><tt>Major</tt></p></dt> <dd><p>Major loss of function</p></dd> <dt><p><tt>Minor</tt></p></dt> <dd><p>Minor loss of function, or other problem where easy workaround is present</p></dd> <dt><p><tt>Trivial</tt></p></dt> <dd><p>Cosmetic problem like misspelt words or misaligned text</p></dd> <dt><p><tt>Enhancement</tt></p></dt> <dd><p>Request for enhancement</p></dd> </dl> <p>Priority describes importance and order in which bugs should be fixed. The highest priority is <tt>P1</tt> and the lowest is <tt>P5</tt>.</p> <p>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.</p> <h3><a name="triage">Triaging Bugs</a></h3> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>These are the triaging actions for the Bug states:</p> <dl> <dt><p><tt>SUBMITTED</tt><p></dt> <dd><p>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.</p> <p>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).</p> <p>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 <tt>OPEN</tt> state.</p> </dd> <dt><p><tt>OPEN</tt><p></dt> <dd><p>The severity and priority of all <tt>OPEN</tt> bugs should be monitored and updated as higher priority bugs get closed by developers and new ones are added from the <tt>SUBMITTED</tt> state.</p> <p>Bugs that contain feature requests (i.e., not problems with existing AbiWord features), should have their severity changed to <tt>Enhancement</tt> - and be prioritized accordingly.</p> <p>Developers assign themselves to work on bugs while they are in the <tt>OPEN</tt> state. When done they will move the bug to the <tt>QA TO VERIFY</tt> state.</p> </dd> <dt><p><tt>QA TO VERIFY</tt><p></dt> <dd><p>The developer has checked in a fix for the problem described in the bug. <em>Someone else</em>, preferably the reporter, must rebuild the latest sources and check that the problem has indeed been fixed.</p> <p>Make sure that you only close bugs 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.</p> <p>When moving a bug to this state, remember to set the resolution correctly:</p> <dl> <dt><p><tt>FIXED</tt></p></dt> <dd><p>A fix for this bug is checked into the tree, and it has been independently tested that it did fix the problem.</p></dd> <dt><p><tt>INVALID</tt></p></dt> <dd><p>The problem described is not a bug.</p></dd> <dt><p><tt>WONTFIX</tt></p></dt> <dd><p>The problem described is a bug which will never be fixed.</p></dd> <dt><p><tt>REMIND</tt></p></dt> <dd><p>The problem described is a bug which will probably not be fixed in this version of the product, but might still be.</p></dd> <dt><p><tt>WORKSFORME</tt></p></dt> <dd><p>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.</p></dd> </dl> </dl> <h3>Bugday</a></h3> <p>Bugday is when people interested in AbiWord meet on IRC (channel <tt>#abiword</tt> on <tt>irc.gnome.org</tt>) to work in concert on triaging the bugs.</p> <p>The bugday coordinator (nick prefixed with _) will try to help direct people to work on various bugs (or ranges of bugs) to prevent people from stepping on each others toes.</p> <p>It's pretty informal though, so don't expect too much. Bugdays are normally announced a day or two in advance on the developer and user mailing lists.</p> <h3>Be Polite and Helpful</h3> <p>Be polite and informative if closing a bug report. We want to encourage people to keep filing <em>good</em> bug reports. They will stop doing that if they feel their effort is not appreciated.</p> <p>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!</p> <? show_footer(); ?> </BODY></HTML>
