# Problem Management

This chapter is a first draft. It contains some ideas that have to be validated by the developer community.

## Reporting problems

Problems (that covers errors, enhancement request, etc.) concerning the &app; project are maintained using the SourceForge.net platform. This is the sole location, where problems have to be reported. The source for such a problem report can be one of the developers or any other user of &app;.

### Referencing problems

Once added to the database, the problem will be assigned a unique problem number. This number must be mentioned whenever the problem is referenced (e.g. in the subject of a mail to the developer mailing-list, a checkin comment or an entry in the ChangeLog file). To allow searches for the number, a specific format has to be used for these references.

The format is `#assigned-number`, e.g. #481229.

## Problem attributes

Besides the fixed problem number which is created when the report is filed, each problem has a couple of attributes that might change during the life-cycle of the problem. They will be described in the following chapters.

### Reported By

As the problem number, this field is fix. It represents the SourceForge username of the individual who filed the report.

### Severity level

The SourceForge.net platform allows to assign a severity level to each problem. It ranges from 1 to 10. The meaning in our project and the consequences are defined as follows:

FIXME: A more detailed description of the prios needs to be given

1. Lowest priority

2. TBD!

3. TBD!

4. TBD!

5. Medium priority (default)

6. TBD!

7. TBD!

8. TBD!

9. TBD!

10. Highest priority

### Area

TBD!

### Assignee

This field represents the SourceForge.net username of the individual working on the problem. Each developer should pick problems he feels competent to work on. The possibility to assign another developer to a problem should be used only to gather a comment from this developer. This should be clearly marked as comment with the report.

The number of unassigned problem reports should be 0 most of the time to give clear signal to the world that the developers are working on the project!

### Status

Each problem has a status. Right after filing a report, it will be assigned the status 'open' automatically by the SourceForge.net platform. Whenever a developer is working on the problem, he will have to modifiy the value of this field to reflect the current status. The following values are available and have the associated meaning:

#### Available problem status values

Status | Meaning
--- | ---
open | The problem is not yet fixed. A developer might be working on it.
closed | The problem has been closed. No further action is required.
deleted | ???
pending | The problem has been modified solved and feedback from the original poster is required. Pending entries will turn into closed entries after 14 days.

### Resolution

The following values are available and have the associated meaning:

#### Available problem resolution values

Resolution | Meaning
--- | ---
Accepted | The problem report has been accepted by the developers. Nevertheless, it has not yet been duplicated but from the initial report it could well be a problem with &app;
Duplicated | The problem has been duplicated by one of the developers.
Fixed | The problem has been fixed. The code is available via CVS.
Invalid | The report is not valid. It's not a problem related to &app;.
Later | ???
None | ???
Out of date | The report is based on an older version of &app; and has been resolved in the meantime in a newer release which is available for download or CVS.
Postponed | The problem has been acknowledged but will be postponed until later. The developer changeing the state to Postponed should leave a comment with the entry why it is postponed.
Rejected | The problem has been rejected by the development team. The developer changing the state to Rejected should leave a comment with the entry nameing the reasons for rejection.
Remind | ???
Wont fix | ???
Works for me | The problem cannot be duplicated but seems to be a valid problem. The entry needs more investigation.