Recommended process for issue state management?
What is the recommended way to manage an issue's state? Specifically:
1. A user captures a new issue - default state is Submitted
2. A developer starts working on it, manually marks it as In Progress
3. Developer hits a snag and needs more information from the user - so he posts a comment with a question for the user and changes the state manually to say “Waiting on Client”
4. The user responds in a comment with the relevant information.
My question is - at step 4 - is the onus on the user to change the state away from Waiting on Client to something else? How would I know - except for the email with the comment - that the state is no longer Waiting on Client?
Please sign in to leave a comment.
Hi Waldo,
This is Julia from YouTrack Support.
There's no universal recommendation - the process should always be tailored to the particular needs of your team. So, to answer your question, it's important to understand who the user is in the described scenario. For example, it may be a QA engineer from the same team as the developer. In this case, the user knows the processes already and is probably quite familiar with YouTrack. So, it's reasonable to expect them to change the status so that the developer knows the issue requires their attention. It should still be communicated somehow beforehand though - say, you can write a short guide on how to report issues to developers.
If issues are reported by external users (or even internal users who aren't often exposed to YouTrack), the opposite makes sense: the process should be as straightforward for them as possible. So, it's better to reopen the issue automatically after the user responds. YouTrack offers a special helpdesk workflow for that: Reopen When Reporter Adds a Comment. You can attach it to your project or implement something similar according to your needs.
Please let me know if you have any questions!