We use the Jira issue tracking system . JIRA is a bug tracking, issue tracking, and project management and we use it for bugs, improvement requests as well as to log desired future enhancements.

Below is a more detailed description of the workflow we use. Please note that only well defined issues can be worked on. Therefore we expect that with the exception of clear bugs, issues are first discussed on our mailing list and first after we reach consensus on what the issue actually is we file a bug in Jira. 

Issue Type

The issue type describes what motivates a proposed change:

Bug

A problem which impairs or prevents the functions of the project.

New Feature

A new feature of the project, which has yet to be developed.

Task

A task that needs to be done.

Improvement

An improvement or enhancement to an existing feature or task.

Issue Priority

The issue priority describes the importance of the issue. In decreasing order of importance, the priorities are:

Blocker

Blocks development and/or testing work, production could not run. Any problem that prevents the project from being built is automatically a Blocker.

Critical

For a Bug, this means that the bug causes crashes, loss of data, or a significant memory leak.

An issue priority of Critical or Blocker whose Fix Version field is set to an unreleased version label (a planned future release) is a release critical issue; it is considered important enough that the release will not normally be made until the issue is resolved. Issues with the lower priorities below are release candidate issues; changes to address them may also be submitted for the planned release, but if all higher priority issues are resolved the release coordinator may elect to defer them to some future release.

Major

For a bug, an important loss of function that falls short of the Critical level, or in the case of a proposed feature or improvement, a significant upgrade.

Minor

A small problem or proposed improvement.

Trivial

Very small, but worth recording.

The status records the workflow progress of the issue:

New

This is the default status for a new issue; it indicates that the issue has not yet been reviewed by a developer. The project coordinator is responsible for monitoring the project for new issues, and ensuring that each is reviewed and either accepted or returned for more data.

Open

When a New issue is accepted, it becomes Open; this indicates that the issue is probably a real one and that there is probably enough information to begin investigation, but that it is not being actively worked on by anyone at this time.

In Progress

Someone (the Assignee) has taken responsibility for this issue and is working on it.

Need Information

This indicates that more information is needed from the reporter (or current assignee) before the issue can be Resolved; the comments must explain what information is needed.

Resolved

A submission has been made that addresses this issue, and the submitter believes that change to be complete. The comments in the issue description must indicate the subversion revision number (or numbers) that satisfy the issue. Normally, when an issue is status is set to Resolved, it is also assigned either back to the person who originally created the issue or to another appropriate reviewer to confirm that it is fully addressed.

Closed

The issue is fully addressed. If a change was made to address the issue, then the Fixed Version field indicates the release in which the change is (or will be) available, or the branch to which it was submitted (if a specific future release from that branch has not yet been defined).

Reopened

This is the same as Open, but indicates that it had previously been either Resolved or Closed; the comments must explain why the issue was reopened.

 

Fix Version

Version numbers and branch names may appear in an issue in either of two fields: "Affects Version/s" and/or "Fix Version". For a Bug issue, the Affects Version/s field should include all versions where it is a problem. The Fix Version field is used slightly differently - for planned releases it indicates when a fix is expected to be available. If it it set to a branch name, then that is the branch where the fix is (or will be, depending on the issue status) available. The Fix Version field may also be empty - this indicates that there is no plan yet to address the issue.

Assignee

The assignee is the developer responsible for an issue. If the Assignee value is Unassigned, then no developer has committed to resolving the issue - contact the project coordinator to volunteer to take responsibility for it, or (if your tracker account permits), you can assign it to yourself.