Here you can find a description of how we manage the issue status in the project

We use JIRA for task management and the following description of our work flow directly reflects the issue management processes modelled in JIRA.

Task lifecycle

The following steps describe the lifecycle of a Bitmagasin task

Triage

When ever a issue is uncovered which needs to be handled at some point, a issue should be created in JIRA to register that we now have identified a new task which needs to be handled at some point. The following aspects of the issue should be considered:

A descriptive summary which makes it easy to identify the isse later on.
Optional attributes are:
- Maybe a short description clarifying the scope of the issue. If any known output artifacts are know at this point they should be mentioned, they could be links to wiki pages or test cases.
- If the issue is related to any of the logic components defined in JIRA, these should be selected.
- Does the issue naturally fall into one of the defined versions (milestones and iterations), this should be indicated. Else leave the issue unscheduled (no fixed version).
- Try to estimate the size of the issue by specifing an original estimate.

Open

The issue is ready to be handled. When a issue is in state open it will typically be enriched a couple of times through:

Backlog grooming The projects task responsible (properly the project manager) will look through all newly created task to see if any further information should be added. We will also try to run through newly created task in our weekly meetings, to evaluate the new issues. One central piece of relevant information which should be defined is which iteration or milestone the task should be put into.
Iteration planning: During the iteration startup meeting (see Iteration plan ) the team will run through all the tasks assigned to the iteration for further qualification, including adding of assignee.

In progress

Work on the issue is in progress. Before work is started, the assignee should find a inspector to assist in discussion the task and solution. The inspector should be contacted before work on the task is started to run through the task definitions to see if anything should be change or added. One important aspect of the issue to consider before starting work is what the output should be, eg. list the affected wiki pages, acceptance tests, etc.

Ready for review

The solution output should be review by one (the inspector) or more persons. This includes documentation, implementation of automatic tests, sanity test and regression test.

Resolved

The issues has been solved and the solution has been checked through a review.

Closed

The solution has been found to work in the context of the full system. For technical tasks this would mean the solution has been released, and has therefore been through a release test.

For non-technical tasks the trigger for the status change isn't as clear, but can be based on the solution being part of the project for a while without any major complaints. Eg. all issues which has been resolved for more than a week is set to closed. Another criteria could be that milestone, which the issue is part of, has been finished.

JIRA workflow

We use JIRA workflow mechanisme for modeling this behaviour. You can find a diagram of the full issue workflow here .

Browser not supported