How to track 'Implementer' in Jira (vs. Assignee)

[Martin Ba]

This is a re-post of a question at S.O.

Our JIRA workflow for development issues goes something like this:

New -> In-Progress -> Resolved -!-> Reviewed -> Closed/Released

This is simplified, but should get the point across.

The Jira Assignee for New/In-Progress is simple: It may start out being assigned to anyone, but as soon as it's in-progress the developer that codifies the issues is the Assignee.

When the developer is done he will check-in and set the issue to Resolved.

Now my "problem"(*) starts: Since the developer should not review the issue himself, the issue should be assigned to someone else for review. The reviewer can then approve it and set it to Reviewed, after which it is ready to be included in a release. (details on how that works not relevant here)

The issue then ends up with the Assignee set to the reviewer, where the relevant person for the issue is actually the original developer.

I mean: When looking at Jira issues, I'm mostly interested in the Implementer, not the person that approved the change afterwards.

So the question(s) seems to be:

• Jira Assignee seems to be thought to change through the transitions of issues.
• The Assignee may then well end up with a only secondary relevant person when the issue is finally closed. This makes filtering on closed issues harder.
• Is this a real problem, and what solutions are there for this?

I guess one could add additional fields, but the fact that the defaults only have these two People should hint at something?

[Justin Evans]

Hi Martin - this is a common scenario that typically requires a scripting or automation add-on like Power Scripts for Jira. It's actually so common that there's a video tutorial on how to use a workflow post-function to reassign an issue to the previous assignee.

Hope this helps!

[Hopeful]

I realize this question is old, but maybe our methodology will help someone.

We found that review often creates more work for the author anyway.  So we keep the assignee the same until the task is completely approved.  We create subtasks to allow us to assign both an author and a reviewer. 

- Parent task describes the work; subtask for author to implemement, and subtask for reviewer to verify. 
- Author owns the parent task.

- An alternative I've considered is to have the reviewer own the parent task as the ultimate "necktie" in charge of making sure it gets done right; then a subtask is assigned to the author.