A lot of issue and bug trackers give you the option to customize nearly every detail of your interface. This includes custom statuses, workflows, and rules. This is great for the users who want that level of control, but can quickly result in confusion as your organization grows.
Consider the following situation:
Project ABC is managed by Dwight, who has customized his issue workflow to use the following statuses: Submitted, Verified, Cannot Reproduce, Will Not Fix, Resolved, and Awaiting Manager Approval. Dwight’s developers have been using this workflow for several months.
Project XYZ is kicked off, and managed by Jim. Jim prefers a much simpler workflow, so he defines his statuses as Not Started, Started, and Finished. Half of Bob’s developers now split time between Project ABC and Project XYZ.
Before the new project began, these developers used a single list of familiar statuses. Now, however, they have to pause and think before logging or updating an issue. “I’m on Project XYZ, so I need to choose Started instead of Verified. OK, it’s been a few weeks since I’ve worked in Project ABC – should I mark this ticket as Finished, Resolved, or does this one require manager approval?”
As your team grows, your new additions will have their own opinions on how issue workflows should be defined. A savvy CEO’s solution to this would be simple: define a standard workflow that will work in most cases, and require all projects to use it. This is exactly what we’ve implemented in DoneDone.
An issue can move between 13 statuses throughout its life:
- Open – The issue has been created.
- In Progress – The Fixer has acknowledged the issue, and has begun working on a fix.
- Not An Issue – The Fixer has determined that the issue is expected or by design.
- Not Reproducible – The Fixer cannot recreate the issue as described.
- Missing Information – The Fixer needs more details in order to complete the fix.
- Pushed Back – The Fixer had previously marked the issue as Not An Issue, Not Reproducible, or Missing Information. The Tester has now provided more details, and wants the Fixer to take another look.
- Ready For Next Release – The Fixer has resolved the issue, but does not want the Tester to be notified yet. Instead, the issue will be added to a Release – a collection of issues that should all be tested at once. When a project administrator creates a Release Build, the Testers of all the issues will be asked to confirm their issues’ fixes.
- Ready For Retest – The Fixer has resolved the issue, and wants the Tester to confirm that the fix also works for them.
- Fix Not Confirmed – The Tester has tried the fix, but the issue is still unresolved.
- Fixed – The Tester has tried the fix, and it has correctly resolved the issue.
- Closed – The issue should no longer be worked on.
- On Hold – The issue will be worked on at a later time.
- Duplicate – The issue is a duplicate of another issue.
The Issue Workflow
While there are a lot of statuses listed above, DoneDone only shows users the statuses that make sense at any given time. Users will only see a small number of options based on their role and the issue’s current status. For example, if an issue is Ready for Retest, the Tester can only change the status to Fixed or Not Fixed. If the Fixer changes their mind, they can switch the status back to In Progress, Not an Issue, Missing Information, etc.
Overriding The Workflow
Of course, there will always be situations where you need to directly set an issue’s status, regardless of its current state in the workflow. Users can always use the Edit icon to manually change an issue’s status or use the Bulk Edit feature to change the status of multiple issues at once.
Keep it simple
We think DoneDone’s status workflow is a good fit for just about any project — and most of our users have agreed. In fact, we’ve been using nearly the same list of statuses since DoneDone v1 in 2009. (We added the “On Hold” status in March 2015).