Managers for each department need to know the issue loading for their people (and themselves - they'll be in the system too). And it needs to be tracked and updated continually.

We'll be using the system to track R&D projects (ideas while they are small, until they become "products" and get their own management structure), customer support, field service, manufacturing support, vendor issues, contractor issues, continuing engineering, etc. Basically, we need to track everything an under-staffed engineering department needs to get done.

The system must also support bouncing ownership of an issue between informal teams, so engineering might only be involved at the beginning and end, and the money folks would be in the middle.

Having multiple assignees is the first step toward the capability we need.

This could be fairly simply achieved by having a list of users with definable roles, separate to the Assigned user (who is ultimately responsible for the issue).

http://forums.atlassian.com/thread.jspa?forumID=46&threadID=3447&messageID=80494719#80494719

The main point is that it would be impossible to determine the remaining work per developer, which is a very useful info for team management.

Since this issue has quite many votes, I hope atlassian people reconsider their decision upon this.

I'd also like to see Atlassian reconsider their decision to place this as an Enterprise feature instead of Normal.

Ben

I believe this kind of a change is an essential change to the conceptual model of JIRA that better reflects how most organizations actually operate. No matter how large or small an organization is, if they need an issue management system bad enough to spend $1000 on it, they will have multiple people working on the same issue at the same time. It is the exception that one person completes all the work for an issue, and a workaround to either perform work in sequence or to create other associated issues for each individuals effort.

Just my $0.02. Thanks for the opportunity to comment.

As to being able to handle the managment issues, if you supported the multiple resources with a representative workflow, then it should be a relatively "simple" matter to extend the management features to take into account the multiple roles. And I suspect that handling a group of people in a single role (actually have 4 developers) as an aggregate should be sufficient.

I would also like to be able to assign an issue to a group of people and allow one of the people in that group to take ownership.

So I understand that other organizations may want this feature, but if you build it, please give us a preference so that we can turn it off. Thanks.

I do see that we might want a slot to record the business-owner in addition to developer, but editable reporters should solve that problem.

This makes sense for some cases, but really doesn't make sense for other scenerios.

We prefer to change owners of tickets as they move through the workflow-- it's just human nature for people to refer to the tickets that they "own," and be less concerned with the other tickets.

It would be cool if someone who was previously an owner automatically became a watcher, as the ticket moves through the process.

In the latest version of JIRA (3.4), it's now possible to add a custom field for multiple users. Thus you could add a custom field called "QA Team", which has the users involved in the QA process of this issue. Moreover, notification schemes can also be based on this field.

This will keep the system simple for most standard installation (there can be a pretty strong case for issues having one responsible "Assignee" even if there is a project team) and let people customize for more complex cases through Custom Fields.

Thoughts?

Cheers,

Mark C

We really need to assign an issue to a group (Several people of the same service). The sub-Task, for us, has an another interest : if issues relate to several services.

This 2 functionalities (assignment to a group and sub-tasks) can be used at the same time.

Of the two, the ability to assign an issue to a group is the most critical...

Example)
Issue 123 Estimated work 100 hours.
Assign Person A with estimated 70 hours of work.
Assign Person B estimated 30 hours of work.
Person A logs 20 hours of work and sets remaining (for him/her) to 55 hours.
Issue 123 Now has Remaining work 85 Actual 20.
Person B logs 5 hours of work and sets remaining to 0 (done!)
Issue 123 now has Remaining 55 hours Actual 25 hours.

– Bill Van Emburg
Quadrix Solutions, Inc.

http://confluence.atlassian.com/display/JIRA/JIRA+3.6+Release+Notes#JIRA3.6ReleaseNotes-grouppickercustomfield

This group picker custom field can be specified in both permission and notification schemes. For example, this allows the list of assignable users to be restricted to the group:

and that group would get email notifications.

If you want to restrict the groups in the 'Assigned Group(s)' drop-down, make it a select-list whose values are group names.

As for reporting, regular JIRA statistics (eg. issues per group) and charts can be used.

As for time tracking, there is an already-popular issue requesting that time estimates for subtasks be aggregated to their parent task:

http://jira.atlassian.com/browse/JRA-3009

If this were implemented, then a task with two "assignees" could be broken into two subtasks each with their own assignee, work estimate and work log. The work estimates would be shown on the parent issue.

Could people requesting this feature have a go at using 3.6's group picker enhancements, and see if a solution based on them meets all their needs?

I selected for it to show on the "Workflow Screen" but do not see it appearing on the issue page. Am I overlooking it?

We need the ability to assign to a group and then change the group on the issue itself.
It would be wonderful if it was possible to add the Group name to the "Assign to" drop-down in addition to the individual names.

The field will show up on the VIew Issue page, only if it has a value. It also depends on how you have arranged your screens. If you are having trouble displaying the custom field please contact our support team - http://support.atlassian.com

Thanks,
Anton

The alternativ to create a custom field with a group picker is not so good because you don't have notification.
For example The group A is the default value in the custom field but if you want to assign the issue to another group (group B) it will be no notification to group B!
How to resolve this problem ?
Thanks and sorry for my poor English

It is possible to add values of a group picker, multi select and select list custom fields to the Notification Scheme. If you are adding a select list or a multi select list you will need to ensure that the options in these fields are named exactly like groups.

Cheers,
Anton

Thanks you very much!!

If this ever gets implemented, I need the ability to prevent multiple assignees in our installation. For us this would preferably be a global option, other users might need an override option per project as well.

Another thought: How would this feature affect the 2d statistics portlet? I would expect that most people find the totals in the following table confusing:

Open Issues by fix version and user

The ideal solution for us is to be able to add a Jira group to the "assignable user" permission, as though it were a user. I understand that there's a knock on complexity to this (what springs to mind is having to mail all the members, and allowing some way for individual real users to use assign-to-me without actually being granted assign-to-anyone permissions), but I think this approach would actually be a lot easier to implement usefully than a multiple-assignee type thing.

Reporting works fine if you treat the group as though it's a user, because it will not look like you have multiple assignees, you simply end up with an extra line for the group.

And for people who don't want it, they simply don't add the group into the assignable permission.

p.s. Yes, the group picker goes some way to help, but it's not quite right.

1) Assigning an issue to a group would cover the bases of notifications and permissions. I only mention the obvious to point out how that part doesn't really change and there's no reason why it needs to be tied in our thinking to the other parts.
2) In order to determine individual estimated workload, you would need an interface that allowed you to allocate the time estimate for that task among the group members.
3) Then everyone logs their own time the normal way and none of the existing metrics would need to change.

Again, the only challenge I see is the proper splitting out of estimated workload, which is handled by #2 above.

In 3.6+ Enterprise you can grant permissions and send notifications to a multi-user custom field (as well as a group picker custom field, described above). So for instance, you could have an "Extra Assignees" multi-user custom field on your issues. When properly configured, anyone added to "Extra Assignees" on an issue would have the same permissions and get the same email notifications as the real assignee. It's effectively "multiple assignees" with a few caveats, eg. users need to define a filter identifying issues they're an "extra assignee" on.

I think this issue should be closed, and new issues raised addressing specific problems with what we have.

I'm not sure that it should be closed. The workarounds work well, but they still don't get round the problem in that users should be able to pick a group when they use the "assignee" field.

I do know that it's not a simple change though. Not at a code level ( I'm a hacker, not a developer, I wouldn't like to try to guess how complex changes might be), but at a design level - there's a lot of potential behaviours that could be quite annoying to unravel. I don't think our site has horribly difficult requirements, but we definitely want to see groups appear in the assignee list, with the option to then assign within that group later. But I can see it could be a lot messier.

That is a solution, but what is the problem it is trying to address? What's the use-case? What do you wish to achieve by "assigning to a group" that you don't get by having an "Extra assignees" or "Responsible Group" (or whatever) custom field? Let's assume JIRA 4.0 with shared dashboards has been released, so you can centrally configure users' dashboards to display a "I'm in a group responsible for" issue filter.

The way I see it, what's possible now is exactly what's needed 90% of the time. A group as a whole takes responsibility, but an individual within the group actually does the work. To model this typical scenario you don't want the "assignee" to be the group - you want to keep the assignee as an individual, and store the responsible group separately (as a custom field). The notion of "is responsible for completing" is separate from "is tasked with completing". The difference would be obvious in practice: when Joe from QA takes ownership, does he change the assignee from "QA group" to "joe"? If so, QA get no further notifications. If not, there's no way to indicate that someone has taken the issue.

The other 10% of the time, you really need each member of the group to "do" the issue somehow, eg. sign off on it. In that case I think allowing parallel workflow step progression (http://jira.atlassian.com/browse/JRA-4147) is a much more important first step.

The use-case is having a single assignee field. You actually say it yourself
> A group as a whole takes responsibility, but an individual within the group actually does the work.

It's not the concept that's the problem, it's the way it handles during the process. We need to create an issue, and assign it to a group, and then an individual within that group takes responsibility for it (whether they assign-to-me or the team lead assigns to them). They do exactly what you say - take the responsibility from the group down to an individual. The assignee field should always indicate precisely who you need to yell at when your issue isn't moving, whether it's a group or person, and you shouldn't have to look anywhere else for that information. "Extra assignees" or "Responsible group" can be useful additions for the people handling the issues, but they presume knowledge on the part of the people raising the issue, or that someone does some sort of triage/work-allocation for each issue, and that gets in the way.

So you:

• Create a "Responsible Group" group-picker custom field.
• On the issue creation screen, prompt the user for the "Responsible Group", and not for the assignee.
• In your permission scheme, ensure that "Responsible Group" custom field members have "Browse", "Assignable" and "Assign" permissions.
• In your notification scheme, ensure that "Responsible Group" members get the "Issue Created" notification.

So an issue is created, and the creator picks the responsible group (or set it automatically in a post-function). Group members are notified. Someone decides to do the issue and sets themself as the assignee.

The other major problem with it is that the group picker is not configurable enough (I apologise if it has improved since 3.6, I've not tried it on later versions), it offers all groups as valid options, whereas we would only need "assignable" groups. It would be no good for our users to select a group that doesn't work on the project that they are interested in.

Bottom line: groups are people too!

I'd suggest these use cases are discussed with the UX group at Atlassian to see what they have to say. I'd not hesitate too much to suggest their opinion might fall on the side of the users providing feedback via this issue..

I would add to his comment the analogy and evolution from using categories to using tags to organize content. "Tagging" is a form of taxonomy and one of those Web 2.0 concepts that is popular due to it's simplicy and expressiveness. With regard to this issue, I believe this would be applied as "assignee tags" – where multiple assignees (either groups or persons) could be tagged to an issue as being responsible for the issue.

Organizationally, it's almost always important to have a chain or responsibility, so it would be reasonable that there be a method to identify that chain of responsibility. This could be simply by making order significant in the "assignee tags" associated with an issue. A slightly more complicated approach would be to have a "primary assignee" token associated with one of the "assignee tags".

Having the ability to "tag" an issue with secondary groups or persons would be a excellent feature. However, that is a separate issue than the ability to assign an issue to a group. Perhaps this issue should be split into two issues?

Robert also reminds us this issue is 5 YEARS OLD. Take a quick look at the change log for JIRA to see just how many issues with a high number of votes have been addressed in the last two years. According to JIRA's own issue tracker, NONE of the :

http://jira.atlassian.com/secure/IssueNavigator.jspa?sorter/field=votes&sorter/order=DESC

This issue is #6 on the list of most popular JIRA issues. Given Atlassian's lack of performance and distraction by other products, I for one am voting to not renew our support agreement until Atlatssian shows some sense of support for their own product and address the top 10 issues. Anyone else feel the same?

Jira Tickets Sorted By Votes

This is a list of ALL JIRA defects (not counting duplicate or cannot-reproduce) in the history of the product, sorted by Votes. What this tells us is that, historically, 74% of the most-complained-about issues are never fixed (only 13 out of the top 50 had a Fixed resolution.)

And yet they are rolling out "new" products right & left. Wonder if those new products will also have the same level of disregard.

Speaks volumes!

Its a funtion like 25 specific persons have to review an issue befor it's resolved.

We tried to create clones or subtasks for this, which would work but is too complicate to use.

Is there a way to create a subtask for each user of a specified group, assigning it automaticly one to each groupmember?
This should also work for the timetracking.

Or is it possible to write a feature like "reviewers" where every selected reviewer can press a link on the issues default screen saying "ok, reviewed"?
This would actualy be very similar to the "watch" functionality. Since it is possible to add several people to watch, and they can use the operation link to "unwatch".
So we could missuse the watch functionality, but we actualy like to keep it for its purpose.

Carl Courtie

This functionality would make a big difference where work can be assigned to a team rather than the lead or manager this way what is assigned directly to an individual is actually assigned to them, whatever is assigned to the group can be actioned by any member of the group as time permits.

Just my 2c

• Assign to individual
• Assign to a project role
• Assign to a group
  from here you can assign to a group, individual, or a project role as part of your process.

The first person from that group could pickup the issue and use the assign to me option, and from that moment on the issue would have a unique owner.

Vielen Dank für Ihre Mitteilung.

Momentan bin ich abwesend.

Ich bin ab 25. Mai wieder für Sie da. Ihre Mail wird NICHT automatisch weitergeleitet.

Falls Ihr Anliegen vorher Aufmerksamkeit erfordert, wenden Sie sich bitte an +41 41 727 21 31 oder support@systransis.ch

------------------------------------------------------------------------------------
Notice of absence:

Thank you very much for your inquiry.

At the moment I am away from my desk and my e-mail.

I will be back on 25 May. Your e-mail will NOT be forwarded automatically.

Should you need to contact someone before this date, please call +41 41 727 21 31 or send a message to support@systransis.ch

I think this would not mess up the time-tracking. Here is what I propose:

a) Reporter creates an issue (X) and assigns to a group.
b) Reporter indicates whether she wants i) the issue to be closed by the first person to complete it or ii) when all people complete it.
c) Jira clones the issue for each user in the group and links the cloned issues (X.1, X.2,..,X.n) to the original issue (X).
d) If the Reporter said "first to close", then when the first person to close an issue closes it (e.g. X.3) the remaining (X.1, X.2, X,4...X.n) are closed automatically.
e) If the Reporter said "all to close" issue X is only closed when X.1, X.2,...X.n are all closed.