views:

1276

answers:

4

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 untill 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) is 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?

+3  A: 

Last year we have the same problem, and we figure out that the best solution for us is Jira. With respect our work flow is more robust and complicated than yours.

vaske
+1 Jira's customizable work flow and integration with Subversion seem to fit the problem quite well. I've used it similar situations with no more pain than the process itself causes.
Ken Gentle
Jira + Fisheye + Crucible FTW
steve_c
+1  A: 

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.

Nikhil Kashyap
how do you work around the feedback issues?
A: 

I've been using Trac for a small personal project, and at work we used Bugzilla for this.

The workflow you described also sounds like how Red Hat utilizes Bugzilla.

warren
A: 

As other's have said, Jira is very good. I especially like its ability to create a custom issue workflow

toolkit