Difference between revisions of "Bug Triage"

From ADempiere
Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.
(adding group)
Line 11: Line 11:
 
The Project Management Committee has established guidelines for using the priority field in the SF bug tracker.  This was discussed in the PMC meeting of 03/06/2007, the notes are here:  [[CC_Meeting_Full_20070306]]
 
The Project Management Committee has established guidelines for using the priority field in the SF bug tracker.  This was discussed in the PMC meeting of 03/06/2007, the notes are here:  [[CC_Meeting_Full_20070306]]
  
If you are filling out a report, you can assign priority according to the following guidelines:
+
If you are filling out a report, you can assign priority and group according to the following guidelines:
 +
 
 +
=== Priority ===
  
 
* Priority 9 - system stopper - data corruption without workaround
 
* Priority 9 - system stopper - data corruption without workaround
Line 18: Line 20:
 
* Priority 3 - problems with workarounds - performance problems
 
* Priority 3 - problems with workarounds - performance problems
 
* Priority 1 - presentation problems
 
* Priority 1 - presentation problems
 +
 +
=== Group ===
  
 
It's very important also to assign the group for the bug:
 
It's very important also to assign the group for the bug:
Line 24: Line 28:
 
* Module specific - if you're reporting affecting just a specific module (not core)
 
* Module specific - if you're reporting affecting just a specific module (not core)
 
* Report - if you're reporting problems of presentation or reports
 
* Report - if you're reporting problems of presentation or reports
 +
 +
=== Release ===
  
 
From time to time, the bugs will be triaged to re-prioritize them according to these standards.
 
From time to time, the bugs will be triaged to re-prioritize them according to these standards.
  
 
Priority and group are important, because we will not announce a stable release while there are known priority 9 bugs on core.
 
Priority and group are important, because we will not announce a stable release while there are known priority 9 bugs on core.

Revision as of 15:07, 28 November 2007

Here we document the meaning of the priority levels assigned to reported bugs.

Where the bugs are

SourceForge Bug Tracker

SourceForge UI Tracker

How to Prioritize

The Project Management Committee has established guidelines for using the priority field in the SF bug tracker. This was discussed in the PMC meeting of 03/06/2007, the notes are here: CC_Meeting_Full_20070306

If you are filling out a report, you can assign priority and group according to the following guidelines:

Priority

  • Priority 9 - system stopper - data corruption without workaround
  • Priority 7 - security issues
  • Priority 5 - not prioritized
  • Priority 3 - problems with workarounds - performance problems
  • Priority 1 - presentation problems

Group

It's very important also to assign the group for the bug:

  • Beta - if you're reporting a bug over a beta functionality
  • Core - if you're reporting a bug over a core functionality
  • Module specific - if you're reporting affecting just a specific module (not core)
  • Report - if you're reporting problems of presentation or reports

Release

From time to time, the bugs will be triaged to re-prioritize them according to these standards.

Priority and group are important, because we will not announce a stable release while there are known priority 9 bugs on core.