Updating tracker items

Other languages: العربية Català Česky Deutsch English Español Français Italiano 日本語 한국어 Polski Português Português do Brasil Русский Slovenčina 中文

We very much appreciate the feedback we get from users. They usually report their findings (bugs, feature requests or patches) here: Launchpad Bug Tracker summary. We can use help in testing bug reports, trying to reproduce them and add more information that might help solve the problem. For example, sometimes a bug might already be fixed, and the issue can be closed. This would help the developers a lot in concentrating on the bugs that still exist.

Updating Tracker Items

This is the general methodology for dealing with SourceForge Bug, Feature, and Patch Tracker items:

1. Be polite. It takes some effort on the part of the user to come to our site, navigate to the bug report section, and write up a report. If they know their report will be treated seriously and professionally, they'll respect the system and put in extra time to help us solve the issue.
2. Do not close an unreproducible bug unless a reasonable amount of effort is put into reproducing it, and let it rot for some time before closing -- someone may come up with a better report in comments. (In a few situations we've not been able to recreate the bug, but due to the involved assistance of the user have been able to narrow down and fix the problem, and the user's been able to do the validation.)
3. Clarify. If it took you some time to guess what it's about, take another second to reword the title or add a comment, to make it obvious to whoever will be reading the tracker after you (especially if it's the person who can fix it).
4. Document your solution. When closing a bug as fixed, add a comment about how you did it (especially what files changed and what to look for in these files).
5. Prioritization: even though SF permits 10 levels of priority per bug, there doesn't seem to be much need for more than four levels: high(9), med(6), low(3), and unprioritized(5). There is no way to predict what features developers will want to work on so prioritization is used to indicate the importance or 'criticality' of an issue rather than when it might be implemented or even how difficult it migth be to do.
   1. Crash bugs are generally always high(9), as are bugs related to file open/save problems, file corruption, loss of backup, or other things that could cause data loss for users or prevent them from being able to use the application.
   2. Bugs which affect usability, functionality, behavior, etc. are generally medium(6), although important ones are bumped up to high and unimportant ones are dropped to low.
   3. Quirks, really obscure things, and minor nit picky things would be low(3).

The prioritization level isn't used to indicate when the bug will be fixed. Bugs seem to get fixed whenever their time has come. That said, we do try to make an extra effort to address all the critical bugs prior to a release.

Duplicates

Always search for similar or Duplicate requests before filing new reports. When choosing which duplicate to close older reports should be given priority over newer reports. Exceptions can be made if one report has signficantly better information provided, and some priority should be given to non-Anonymous reports since there is a better chance of getting followup information from users. When closing a report as a duplicate make sure to include a full hyperlink to the report being left open and preferably the bug title/summary. Where appropriate copy and paste across any relevant extra information to the bug report being left open.