Is our bugtracking workflow so unique? [closed]

Question

We're currently using Mantis as our bugtracker, and we're pretty much sick and tired with it. The developers want more SVN integration, the customers want an easier system to work with.

As such, we're looking for a new bugtracker and at the moment we're looking at Redmine. However, in its default setup it doesn't match our desired workflow, or at least not much better than Mantis does.

We have the following workflow, and would like a bugtracker to match it.

• A bug is reported (often by the customer), and is considered 'new'. These bugs are regularly reviewed and either acknowledged (it's a bug) or marked as a feature (customer often needs to pay) and delayed until the financial part has been worked out.
• The bugs are then assigned and handled by a developer
• when finished, it's marked as 'ready-for-review' (by another developer)
• when reviewed it's marked as 'reviewed'
• when marked as 'reviewed', the original developer places the new code at the staging environment and marks the bug as 'ready-to-be-tested' (by the bug-reporter)
• bug-reporter marks the bug as 'resolved'
• when placed on production, bug-reporter closes the bug

Of course, feedback is often required especially during the early stages. We're looking for a way to distinguish between who is required to take the next step, and who the bug is assigned to (developer). We also want the customer to do so using a simple gui - asking them to change the assignee from their own account to the developer, or even more difficult: a 3rd party (think: design agency) has just too much to ask using the regular gui's. The gui should show them what to do and which options there are - not search for them.

Does anyone have any experience with a bugtracker that works this way? Is our workflow really wack? How do you make sure everyone involved understands where the bug stands, and who is required to take which step?

Answer 1

Last year we had the same problem, and we figured out that the best solution for us was Jira. With respect our workflow is more robust and complicated than yours.

Answer 2

We have pretty much the same kind of workflow which we are managing using Redmine with email integration. The customer logs bugs into Redmine directly. Notification comes to the project manager who decides which developer can work on the bug. The developer opens the bug and puts it into the Investigating state. If its a feature, he replies to it stating the reasons and puts it into the Replied state which is then revisited later. If its a bug, then the developer starts development. Before this he puts the bug in Coding state. Once the coding is over, he changes the state of bug as Review and the peer reviews happen. If there is any rework, then the developer changes the state to Rework. Once everything is ok, the developer changes the state to Delivered. The QA verifies the bug and the finally closes it by changing the state to Closed.

We've defined all of this workflow in Redmine and have been using this pretty effectively without any hassles. Email integration makes everything easy for the project manager to track whenever any bug changes its state. You can also create and save custom reports, which is a cool feature as well.