The main goal of issue tracking is to capture issues and drive them all the way to closure. A ticket is reported and our aim is to have it fixed or resolved and then close it off. Of course, each issue needs to progress through several stages before it reaches it’s final resting place and it’s important to clearly define your overall process for issue tracking and then to align this with the status at which an issue can be placed in at any particular point. This typically refers to your issue life-cycle.
MantisHub defines 7 statuses for you to reflect status of your issues. Below outlines how these statuses would be considered in a traditional software development process but you’ll see that much of this is transferable to any issue tracking scenario.
- New – This is the landing status for new issues and indicates it’s waiting on some review or action.
- Feedback – This status is used to reflect that the issue is pending on feedback from the reporter. So is used when more information is needed.
- Acknowledged – This status is used by the development team to reflect their agreement to the suggested feature request. Or as supporting what the reporter is suggesting.
- Confirmed – This status is typically used by the development team to reflect that they agree with what the reporter is suggesting in the issue and that they have confirmed and reproduced the issue.
- Assigned – This status is used to reflect that the issue has been assigned to one of the team members and that the team member is actively working on the issue.
- Resolved – This status is used to reflect that the issue has been resolved. For added information, an issue can be resolved with one of many resolutions. For example, an issue can be resolved as “fixed”, “duplicate” or “won’t fix”.
- Closed – This status reflects that the issue is completely closed and no further actions are required on it. It also typically hides the issue from the View Issues page. Some teams use “closed” to reflect sign-off by the reporter and others use it to reflect the fact that the fix has been released to customers.
Typically issues would move through new to closed but of course you may need to return to a previous status, for example a new development while in assigned state may require you to go back to feedback for some more information from the reporters. Or after resolution, the ticket needs to be re-opened. And some statuses may be skipped altogether, perhaps your smaller teams may not need to go through the acknowledged stage. Others may wish to skip resolved and go straight to closing the issue.
When determining your specific workflow and how they align to MantisHub statuses. It’s important to note that each of these 7 statuses map to one of 3 definite stages in an issues life as this will affect how MantisHub treats issues. For example,
- any status related filters use this (e.g. hide status field).
- Some workflow settings depend on these such as ‘when is an issue read-only’, and
- your resolution values need to make sense with the status value. Check out our KB article on valid combinations of status and resolution for details.
MantisHub determines this relationship by assigning a code to each of these statuses and using this to define the 3 stages.
- Open – at this stage, your issue is needing attention and actively being worked on. It will appear in filters and reports as open tickets. This stage covers the new through to assigned statuses or code values 0 to 79
- Resolved – at this stage your issue has been addressed but there may be some follow up (e.g. release, documentation, notifications etc). This stage contains the ‘Resolved’ status or code values 80 to 89.
- Closed – all work relating to this issue has been completed. This stage contains the closed status or code values 90 and above.
These stages and code values are particularly important if you’re considering customizing your status values.
Customizing your statuses
The 7 default status values do work really well for the vast majority of our customers. The terms are generic, intuitive and flexible enough to apply to any environment. However, we do offer the option to customize this for qualifying plans. The most simple changes are hiding any of the existing defaults that you find are not being used or changing the name or color for existing defaults. Not so straight forward but also commonly used are adding in some extra custom statuses.
When adding custom values here, there are 5 items of information you need to provide. While it’s tempting to just provide the new status name, you also need to define some peripheral terminology for the system such as what phrasing you want for email notifications. And it’s important to make sure to provide the requested terminology for any specific languages in which you use your system as these are not included in the system translations. All the details can be found in the KB article customizing issue statuses.
Workflow transitions
Another way to customize your workflow is by locking down transitions between each status. By default you can move freely from any status to another. But you may want to lock in certain behavior. For example, you may want the system to work such that once a new issue is changed to a higher status it can’t go back to being new. So you can disallow transition from any state back to ‘new’. Or perhaps you want to make sure all tickets go through the resolved state before being closed, so you would disallow all transitions to the closed state, except the transition from resolved state.
You can also lock down transitions according to a users access level. By default, developers and above are allowed to change an issue to each status, the only exception being that reporters can of course create issues in the ‘new’ status. There is simple check box configuration option to give reporters permission to re-open issues or close and this is configurable in the workflow thresholds.
To give you an example of making use of workflow transitions, lets say you want all managers to sign off on issues before they are closed, then you could set the minimum access level allowed to transition to closed status to be manager. Check out the article on workflow transitions for more details.
Helpdesk workflow
When using MantisHub Helpdesk to handle incoming customers tickets submitted via email, MantisHub suggest a number of tips and shortcuts as well as a specific workflow. In a customer support scenario, your issues or tickets will transition frequently between the feedback and assigned statuses. When responding to customers, you should set the status to feedback indicating you are waiting on a response from the customer. Once a customer replies, the ticket is automatically set to an assigned status indicating it’s waiting on your action. The workflow suggests a streamlined approach for handling these tickets and also takes into account which types of activity within the ticket will trigger notifications to your customers. Have a read of this article and many more on our Helpdesk feature for your customer support needs.
Addressing your workflow process and utilizing our intuitive issue life-cycle will definitely save your team time and money. Or consider tapping into the many ways you can tailor it to your needs. Improve efficiency and create simplicity in your issue tracking process and get closure :).
MantisHub 