Difference between revisions of "Updating tracker items"

From Inkscape Wiki
Jump to navigation Jump to search
 
m (link fix)
Line 1: Line 1:
=== Updating Tracker Items ===
=== Updating Tracker Items ===


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


# 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.
# 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.

Revision as of 02:33, 22 January 2006

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). We use the prioritization for 'criticality' rather than implementation order (which is unpredictable).
    • 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.
    • 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.
    • 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.