Redmine Workflow - iToto/developmentCycle GitHub Wiki

When working with Redmine issues for InSight we’ll be using a new workflow. There are several new statuses to be used that will more accurately describe the state a given issue is in.

The statuses are as follows:

This is a newly logged issue. Nobody has looked into the issue at this point. It’s an “idea.”

Someone is currently analysing this issue. By either investigating a bug or writing up documentation on what is required. It is expected that the result of the analysis is either :

• A full solution documented in the issue’s description, and split up into sub-user stories and estimated subtasks. The solution should be clear and leave little room for interpretation.
• Rejection of the issue, with explanation in comments.

A full solution was written as part of the analysis and awaits approval by a project manager. The project managers can request changes or clarification. Only once their approval is given can development begin.

A developer is currently implementing the solution suggested in the analysis.

This issue is being tested by QA

The issue is put in this status when we are unsure if the issue needs to be worked on or not. Nobody should be doing any kind of work while the issue is in this status

The issue has passed testing

The code for this issue has been merged into either Master or Development

At any time the issue may be rejected. This means the issue is no longer wanted or needed. This is a closed status. If at a later time we want to re-visit this issue, a new issue should be logged.

From the diagram you can see the flow one can take during an issue. At any time a task may be pu on hold or rejected. It can also go back to the analysis stage if some issue comes up that requires re-analysis, although this is rare as the issue should be split up into a number of unit tests and tasks before hand which should cover most if not all unknowns.