The Piwigo bugtracker we use is designed for two goals : bugs and feature requests management.

This is the most efficient way to ensure bugs get fixed: As long as a bug is not fixed, its issue stays in the bugtracker. Unlike forum posts, it's impossible for bugs entries to be forgotten about.

Feature requests are also managed in the bugtracker. This may be not ideal since it is not exactly the same thing, but there's enough common information between feature requests and bugs to share the same tool.

The bugtracker is currently using Mantis. This tool has lots of useful features. For example, we can automatically generate a list of bugs corrected and features added for a given release.

The difference between the forum and the bugtracker is the level of specialization. While the forum is a very generic discussion tool, the bugtracker is dedicated to tracking tickets (bug correction or feature request). If we were using the forum for bugtracking, users would have to be much more rigourous. With the bugtracker, the tool imposes rigour upon users. Users just have to fill in a full set of information and follow the established process.

On of the purposes of the bugtracker is to keep information useable in the long term.

What we can do with a bugtracker we can't do with a forum:

• Follow state of a bug
• Know who is in charge of fixing it
• Know who is also interested in the bug (anybody can subscribe to a bug)
• Know in which release/build the bug was fixed

• Registering is mandatory to submit bugs. No account is required to read the bug database. The bugtracker, forum and wiki do not share user accounts.
• When reporting an issue, fill as many fields as possible and be precise.
• Product version is useful only if you report a bug. Useless for feature request. When reporting a bug on development trunk, give the corresponding build or Subversion revision.

• Target version. Set “target version” for features, not for bugs. target version must be a “big” version, like “Butterfly” (which may become 1.8.0) or Alligator (which became 1.7.0), not 1.7.2 (as we don't plan feature addition on a stable branch). If we haven't decided to plan a feature for big version, don't set the “target version”. It just means that the feature is not in the roadmap.
• When a developer resolves/closes a bug, he gives the Subversion revision in which the fix was applied. A search in Subversion viewer gives all details about the changes made in the code. For example,

- corrected in branch 1.5 svn:968
- reported on trunk svn:969

Syntax svn:<revision> automatically creates a link to Subversion online viewer.

+--------------+
|     new      | submitted and being read by developers
+--------------+
       |
+--------------+
|   feedback   | the issue is waiting for feedback (discussion session)
+--------------+
       |
+--------------+
|   confirmed  | the bug can be reproduced and is waiting for a developer
+--------------+
       |
+--------------+
|   assigned   | a developer is in charge of the issue
+--------------+
       |
+--------------+
|   resolved   | the bug was fixed on the branch corresponding to the
+--------------+ reported release
       |
+--------------+
|    closed    | the bug fix was applied to the trunk
+--------------+

+--------------+
|      new     | submitted and being read by developers
+--------------+
        |
+--------------+
|   feedback   | the issue is waiting for feedback (discussion session)
+--------------+
        |
+---------------
| acknowledged | the feature request is approved and is waiting for a developer
+--------------+
        |
+--------------+
|   assigned   | a developer is in charge of the issue
+--------------+
        |
+--------------+
|    closed    | the requested feature was added to trunk
+--------------+