Table of Contents
Bug Handling
Workflow
Triage | |||
| Stage | Assignee | Status | Action |
|---|---|---|---|
| | |||
| open | none@ qooxdoo.org | NEW | Triagers appoint severity, typically also priority. defects need to be assigned, often with milestone. enhancements may be kept unassigned. |
| | |||
| reopened | someone | REOPENED | Assignees need to re-evaluate the issue. Triagers should be involved when re-appointing severity, priority, milestone. |
| | |||
Commitment | |||
| Stage | Assignee | Status | Action |
| | |||
| assigned | someone | NEW | Assignees need to decide whether to reassign to someone else, to unassign (see “open”) or to keep it. If kept, they are not required to work on it immediately (cmp. “accepted”) |
| | |||
| accepted | someone | ASSIGNED | Assignee decided to work on the issue in a timely manner, i.e. within the next few days. A target milestone is required. |
| | |||
Termination | |||
| Stage | Assignee | Status | Action |
| | |||
| fixed | someone | RESOLVED (as FIXED) | Assignee has regularly fixed an issue. |
| | |||
| resolved | someone | RESOLVED (not as FIXED) | Assignee has resolved a “pseudo” issue, e.g. INVALID, DUPLICATE, etc. |
| | |||
| verified | reporter | VERIFIED | If the bug reporter is not the person who resolved/fixed the issue, the reporter should explicitly verify the issue as resolved. |
| | |||
| closed | resolver | CLOSED | The person who resolved/fixed the issue finally closes it, after verification by the reporter, and after intensive testing (unit tests, CI) and completing docs. |
Queries
Triage
Defects
- open defects framework
(upcoming releases, here 0.9+ or unspecified)
- open defects framework
(upcoming legacy release, here 0.7.5)
- reopened defects framework
(upcoming releases, here 0.9+ or unspecified)
- reopened defects framework
(upcoming legacy release, here 0.7.5)
Enhancements
Commitment
- assigned issues framework
This is the entire “pool” of assigned, but not yet worked on, issues
- accepted issues framework
This should yield a reasonably small number, which can be addressed in about a week
Termination
- resolved issues framework
Beware, this yields many issues, better query per release
- resolved for upcoming release (here: 0.8.3)
This should be down to zero for an official release
- closed for upcoming release (here: 0.8.3)
Administration
The following queries should help in identifying and addressing any inconsistent state of the bug handling data. Typically, those queries target those inconsistencies, so they shouldn’t yield any results.
- targeting upcoming release, but unassigned
(here: 1.0) - targeting future release, but unassigned
(here: 0.7.5, 1.0.1+) - targeting past release, but unassigned
(here: all except 0.7.5, 1.0+)
- reopened for past release
(here: all except 0.7.5, 1.0+)
- resolved as fixed, but not closed, for a past release
(here: all except 0.7.5, 1.0+) - verified for past release
(here: all except 0.7.5, 1.0+)
Relevance
The following table is only an orientation for determining the severity of a bug. It helps with identifying the relative importance within certain criteria, rather than providing an absolute score. Therefore it is to be used qualitatively rather than quantitatively.
| high | medium | low | |
|---|---|---|---|
| Platform | |||
| Browser | Firefox, IE | Safari, Opera | Chrome |
| Browser version | latest major | previous major | legacy, pre-release |
| Browser+OS | IE/FF+Windows, Safari+Mac, FF+Linux | Opera+any, Chrome/Safari+Windows | others |
| OS | Windows | Mac OS X, Linux | others |
| qooxdoo | |||
| Releases | latest stable | latest legacy, previous stable | legacy |
| Affected Users | |||
| Type | end-users | developers | |
| Customers | company | partners | community |
| Number of users | all | many | some |
| Issues | |||
| Type | defect | enhancement | |
| Run-time errors | build | source | |
| Error messages | load-time | run-time | devel-time |
| Build options | no optimization | some optimization | full optimization |
