Evolution of Status and Workflow

General discussion of Mantis.

Moderators: Developer, Contributor

Post Reply
Posts: 217
Joined: 14 Feb 2006, 02:53
Location: USA

Evolution of Status and Workflow

Post by Starbuck »

For different clients and their different projects I try to setup workflow transitions that fit the needs and personalities. Some people don't like a rigid structure. Most people don't like too many status transitions. Some projects don't need a lot of transitions. Some projects do require more refinement with more status codes and role-based restrictions on transitions. I'd like to share one of my workflows here, noting the problems I've seen with it. This might help others to decide to add more status codes/transitions, or maybe to eliminate what they don't use. People might want to make suggestions about how to improve this one workflow, though as I said I do already have variations and I do make occasional changes...

new - standard
feedback - we don't understand, please clarify
acknowledged - ok, we get it, we need to confirm it
confirmed - confirmed, valid issue
hold - decision made to hold this pending some other event
waiting - need info from someone, will be active when they respond
assigned - someone will look at this based on priority and resources
in_progress - working on it!
testing - we're done working, someone needs to check our work
deployment - testing complete, ready for deployment
resolved - it's deployed, we're done, it's resolved
closed - 2-4 weeks after resolution, archive the ticket

That works, but there are challenges.

The thresholds are fluid because some issues can be Resolved without having to go through In Progress: "I read the ticket, it's a non-issue, I just want to Resolve as fast as possible." In the matrix of Workflow Transitions, we can have too many transitions checked, making it too easy for people to make bad choices. We can also have too many unchecked, forcing people to manually transition through status codes with empty Notes just to move on with their work.

Sometimes the developer creates his own ticket and wants to resolve it without going through a Testing status. That's OK. But then developers want to resolve other tickets without going through testing. Or they set a ticket as Resolved before the Reporter has a chance to verify that the issue really has been resolved to their satisfaction. For this problem at one site I added UAT for User Acceptance Testing. All tickets must go through UAT and on Resolution there must be a confirmation from the originator : When tickets are not created by someone in the field we trust that a note like "issue is fixed" on the resolution actually comes from the ultimate Reporter in the field.

An important concept there is "when is a ticket 'Resolved'?" Developers think it's resolved when they're done working on it. OK, do we move from Resolved to Testing/UAT? Or should we have a status after In Progress like "Dev Complete"? It's not really "In Testing" until someone is really testing. Before that it's "Pending Testing".

And is Testing an activity for a separate child ticket? As in : This ticket reports a problem. The child ticket is a request for someone to test the resolution of the current ticket. It gets its own New, Acknowledged, Assigned, In Progress, and Resolved status. When that ticket is Resolved as a dependency, then this ticket can go to to Resolved.

About testing : I'll reiterate that it's important that members of the Developer role should not be allowed to Resolve tickets until Testing is complete by someone other than the developer. "I think it's done, therefore it is" : This is the source of a lot of bugs that get into the field. Without someone else testing a change to verify that the effort has been completed, it's too easy for a new release to be published with reported issues still broken and new issues introduced by bad fixes. For a company that has Quality Assurance resources, we move from Resolved to QA, which is more rigorous than simple Testing.

Yes, sometimes a developer creates a ticket just to remind himself to do something. Other times a member of the Developer role will create a ticket for someone else. He/She can resolve the self-created ticket, but should not be allowed to resolve the ticket for someone else. I don't think Mantis has this kind of refinement built-in. I have custom fields for Reporting Company, Reporting Person Name, and Reporting Person Email. I think a plugin would help here, where if any of those fields are non-null then the workflow should prohibit the originator from resolving the issue without going through UAT.

That brings us to : How does someone in the field get a product for UAT unless the product has been built and deployed? Every situation is different. Sometimes UAT just involves emailing the user with some back and forth Q&A about what's been done, and getting the user/client's verbal OK that it seems like the issue has been resolved. Whatever the UAT process is, it's important that it occurs when it seems reasonable.

The Hold and Waiting concepts were added out of necessity:

Waiting: "Yes, it's assigned to me and I was working on it, but I can't continue until someone else does something." This is a way of removing a task from In Progress, because no work is actually being done on this task. A Manager might be concerned about assigning too much work to one person, when a lot of the tickets are really waiting for someone else's action. This code helps to clarify the actual status. Consider also, a ticket that goes from Testing to Waiting : "It's in testing but we're waiting for some long process to break, or for someone to report an error, or we need to get some special equipment or configuration to continue testing." This status tells us that while a change should be actively in testing, that it's not really. Again, this help with resource/personnel allocation and other management decisions.

Hold: "It's a valid item but we're not going to work on it until the next release." or "We're considering a product redesign where this might not fit anymore." This is a clear signal that we are intentionally not acting on this ticket. It's better than letting a ticket sit in New, Acknowledged, or Assigned status for months or years. (Look at the MantisBT tracker itself for too much of this.) It's frustrating to not know if a ticket will ever be processed. It's reassuring and a matter of courtesy to get some acknowledgement that the ticket has not permanently been left in limbo. Combine this with a Due Date, ETA, or other field to commit to re-evaluation at a time in the future, whether 3 or 6 months or 1 year.

Another concept, that's subject to some debate would be when to use status codes for individual tickets compared to creating parent/child dependencies or just new tickets with a reference. Here is an example where the Deployment status might be better handled in different tickets...

I have Deployment before Resolved, but it's easy to argue that Resolved should come first. That way it shows up in the Change Log which is available in the deployment package. This could mean moving from Testing to Resolved, then Deployment, then Closed. And I think most people would say Deployment isn't a part of this kind of problem resolution, so it should be removed. Indeed, I hardly ever use it. But what's the status of a resolved fix in a release that hasn't been published yet? It's "Pending Deployment". I guess we could say Resolved implies Pending Deployment. Or we can ignore this deployment concept entirely and just say the change for a ticket is available to "whomever has the Fixed In Version" (When that Version has been checked as "Published"). But what is "Deployment"? For some products there's a process that involves building, bundling, documentation, adding notes to a README, creating a marketing blast that some new product change has been implemented, etc. "Why didn't we tell anyone about that new feature?" "We forgot about it." Well, that problem might be fixed if the ticket gets a Deployment status first, and the ticket is only Resolved when the Deployment process is complete.

Yes, another way to do that is to ensure that Marketing and Documentation people get the Change Log prior to a production release. Then they have a list of everything in Fixed In Version. Someone might suggest, and I'd agree, that it might be better to create another ticket that gets assigned to each team for their processing. That ticket would include the ID's of all of the tickets Fixed in Version. Then there is no excuse for not documenting a new feature or a fix. Should a new ticket for diocumentation or marketing be a child dependency on the ticket for a product change? If it is then the product change isn't Resolved until documentation is done. That's good. But to allow a product change to get into the field without being tied to docs, it might be better if a new ticket for docs just reference the product change ticket.

There are many ways to break up the handling of a ticket/task using related tickets, with parent/child dependencies, or to add status values for a single ticket. There are no absolutes. MantisBT offers versatility and options.

The main challenges I face are having too many status codes or not enough, and having too many transitions checked, or too many unchecked. When too many codes are present people just want to skip through them. When there aren't enough, there are a lot of emails and IM chats asking about the actual status of a ticket. Whenever I install Mantis for a new team I start with fewer status codes and I check most transitions. I leave it simple and open for people to just get familiar with the environment. Then as problems occur, bugs get let into the field, people get frustrated about things failing, people spend too much time in email or IM, management gets involved, etc... Then I start to tighten it up with more codes, and with transitions to force more "process" from one step to the next. People usually resent formalization when getting started but after a few months people appreciate how it help them to work better, and they admit that they love Mantis and what it's done to help them.

So there is my open discussion about this one list of status values. Again, I'm not looking for a solution to a specific problem, just discussing some of the challenges that we incur with choices that have been made.

Your turn!
If you want Mantis to work differently, use or create a plugin. Visit the Plugins forums.
Ask developers to create a plugin that you need - and motivate them to help you!
Post Reply