I'm relatively new to JIRA administration and workflow config, though I've worked in software project and process workflow for a number of years. The previous admin at my company configured all workflows and trained users that the initial assignee should never be changed, regardless of the status of the ticket or current responsible party. Instead, custom user fields are set to indicate the code reviewer, QA and internal UAT users, who work the ticket once it hits the appropriate status. The user remains the original assignee (generally, the dev) throughout the entire workflow cycle. I've spent hours reading the documentation and watching online videos, but haven't found any good argument in favor of this practice. Is there something I'm missing that would firmly support the rule that the assignee should never change, even when the current workflow step is another individual's responsibility?
No, you're not missing anything. You've hit on the right idea, and, much as I usually avoid being so blunt, your previous admin was wrong.
The assignee field in JIRA is designed to be "the person who is currently dealing with this issue". If they delegate parts of it out, fine, use sub-tasks or associated issues. If it's a group of people, put a field on it for the group, but "Assignee" is always the answer to "who is dealing with this at the moment". It should change during the lifecycle, unless it's the case of "I raised it and I'll do all of it".
For the other fields, actually, there's nothing wrong with them, and they can actually be really useful. If you know who the code reviewer, QA and UAT users are going to be, by all means stick them on the issue and leave them. They're useful for knowing who to assign to when your bit is done. You can even put it in post functions. For example "when developer finishes and moves issue from "in dev" to "needs testing", copy the QA user into the assignee field"
It's also not a bad thing to record "initial assignee". Again, another field and a post-function to set it would save your users having to think about it, if you can't be bothered to glance at the history. Or a scripted field to pull it from the history.
But, that core assumption that the assignee should not change is totally wrong. Assignee = single person who is working on it now, and it will change as other users need to work on it.
Oh Nic, blunt is perfect. I run into so many people that think they know what they're talking about but in reality are just screwing it up due to a lack of understanding. You're a saint for participating so much here.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
That would be based on what the previous Admin needed. Suppose they needed traceability back to the initial assignee (let's assume a developer). If they needed to generate some stats for each developer (lets say how many issues did they work on in a quarter?) then you might find it convenient to keep separate user fields for different responsible parties.
Just one quick thought
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Of course I would never say never...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes, but this information could be determined using JQL WAS operator (assignee WAS 'johnsmith'), correct?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes, you could do that, but you would loose a lot of flexibility and might end up doing many queries for a simple analysis.
Nic's answer is what I would support, I was just trying to think of why the initial Admin might have done what they did.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I can't think of a good reason to work that way either.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.