Redmine

Some info from #1500:

Since we are using redmine more for issue tracking and task assignment in our team, I have found that the ability to assign a issue to multiple users is very imporment. Especially for task assignment in the daily management, because there are a lot of task need more than one user to complete. For example, 'please report your next month's working plan'.

Maybe some current users of redmine don't think this feature is important, but I think that this feature will extend redmine's application domain much more.

--------------------------------------
2008-06-19 17:43 - Paul Rivier

Comment

Assignee is the person who is responsible to carry the issue to the next step, or next "status". In your example, what would be the current status and the next status, what should each person do about that ?
I guess you can either submit this type of request as an e-mail, or as a news. Or better, as an issue then assign this issue to someone who is responsible to make sure all working plan have been reported.
In other words, what we are talking about here is more about workflow generally speaking, and less about specific feature not implemented in redmine. So please design precisely the workflow you want, then let us know. Cheers

Hi, Jean-Philippe, I really think that assign issue to multiple users is a important feature.
Does the user groups feature in version 0.8 means that a group of user can be assigned to one issue?

Why not to use que of unassigned tasks, and delelopers take tickets from this quee?

Maxim Krušina wrote:

Why not to use que of unassigned tasks, and delelopers take tickets from this quee?

Hi, Maxim, I don't know what do you mean. Would you please explain how to use que?

I have reviewed my request and I think this feature could be like this:

Issue can be assigned to multiple users, and there is a task master among the assignees. The task master is responsible to manage the status of the issue, and other assignees is responsible to report their working status(they report by add note to the issue, this will keep the system simple). So the issue creator, task master and all of the assignees could be involved in the issue and receive the issue change notify email.

This is useful in a team that every member's task is assigned by the leader. There are many daily work task that assigned to different member is same. The leader will find many times that he want more than one member to be involved in an issue, or that he want to choose more than one members who should be notified when he create the issue.

I vote for this feature as well. Maybe there needs to be a Task Master as mentioned above but sometimes when I create a new issue, I need multiple people to be notified and provide input. If there is resistance to adding the ability to have multiple people assigned to an issue, then an alternative might be to allow the creator/editor of the issue to make people watch the issue so they will be notified. This could probably be done with minor UI changes since issues can already be watched by multiple people.

Jason Best wrote:

(...) but sometimes when I create a new issue, I need multiple people to be notified and provide input (...) an alternative might be to allow the creator/editor of the issue to make people watch the issue so they will be notified

This is being discussed in some other threads, for example #515.

The user groups would also heavily decrease the amount of time used on permission management when making new projects would allow to do the permissions group based and not user based. Now making a new project is pain when you have a lot of people that needs access to it.

I reviewed all persons comments. I partly agree some guys' opinion about "Task Master" concept.

I'd like contribute my mind in here.

In fact, assigning one issue to more than one person would cause to logical confusion. I think every individual issue is "Atom" issue, it only can be handled by just one member. If we meet the situation of one issue to multiple member, I think this issue has to be splitted. Split it to more than one issue, and each sub-issue assign to one member. So I suggest using sub-issue concept.

Parent/master issue and all its sub-issues are appurtenant. To manage easily, all sub-issue are still below the parent/master issue(use '+' to spread out, use '-' to pack up). If all of sub-issues are closed, then parent/master issue could be closed. If just only one sub-issue is not closed/fixed, then the parent/master could not be closed.

I say clearly?

I think it would be helpful to have some sort of pair programming support. People have mentioned the idea of a primary assignment, which could work. However, I would definitely like to see some pair support. Quite often, we assign two people to pair up on a task so that they can learn from each other. As it is, we have to create two identical issues and assign them to two people, which causes more confusion that a multiple assignment could dream to cause.

+1

Why?
We've a Sub-project to handle the documentation relative to the Parent Project and we need to assign generally 2 people on a single document to be written.
So, the Issue "Write Requirements Analysis" should be assigned to two users.

We've had to create two equal tickets... Not an elegan solution...

Will be needed even the ability to log time entries for every user the ticket is assigned to.

I also have need of this feature and would love to see it implemented. The "user groups" thing on the roadmap could be great, if you could assign a task to a group instead of to an user.

Has there been any progress with this?. I'd make a patch myself, but I've seen how many places assigned_to appears in and I fear that I would break compatibility to any future version.

BTW, I'm new here. I really like Redmine. Great work!. And happy 2009! ;)

+2

Isn't it better to have just a pool of tasks To-Be-Assigned so the users can pickup tasks from this pool? Because when task is "Assigned" it means it WAS assigned to some user, so it's state after assingation of ticket... Why? Because for us it's very important that ticket is assigned only to one user, because there is direct responsibility. If we allow to assign ticket to more users than one, we'll be in big trouble ;)

Not really. As Andrea Zilio said, we have same tasks, such as documentation, that are worked on by more than one person concurrently, and having to create redundant tickets is a PITA (plus the hours are not accumulated by task in the reports, so you have to calculate the final sum).

What would be nice would be to have the option to allow all issues to have multiple assignees or just one. That way, everybody that is using the actual model would be happy and so would we.

So OK, but it should be a configurable behaviour, now I don't kknow if it should be turned on/off globaly or per project... maybe both?

I think the company that uses multiple assignment will probably use it for all its projects, and vice versa, but if allowing both global and per project configuration is easy, having the option is always good!

Perhaps you could define globally if you want the default assignments to be unique or multiple, and then you can change it for specific projects, if you want to.

We have one related issue. We do some brainstorming for some influential tasks. A few members participate in the brainstorming, and after the brainstorming, one developer will take the responsibility of the development for that task. The present interface to handle such situations is pretty cumbersome. For the brainstorming part, we need to change the task assignee to each member, add the brainstorming time to the time spent by him in Brainstorming activity. Once the developer completes the work, he will add his effort to the time spent in the Development activity, before closing the task. A better interface for such situations, would be of great help in project management.

+3

This is really two different behaviours, isnt it?

1) Assign an issue to a group of people for anyone of them to "take" it (we use atom-feed for this)
2) Assign one issue to several people who work in parallell (i would prefer that to be solved with subissues, see #443, would solv timetracking, workflow and similar)

Our current solution on 1) is to use RSSowl to watch saved filters. That means that several members can watch for the same combo if issuetype, category and status. The member who "take" the task changes status to the next one (usually from a "queue"-state to a "working"-state). When done, do another update with time and comment as well as state-shift to a "done"-state. In this case we never use the field "assigned" at all.

RSSowl present a nice pop-up in lower right corner to avoid filling the mailbox (one client have 100+ issues per day).

/T

Yes your points 1 and 2 are good features, but I think this issue is actually a 3. Which as stated, having more than 1 person assigned to a task. Take the brainstorming example above, there is no subissues in that, it's just an issue being solved by many people. if your brainstorming team is 10 people you dont want to spend the time creating 10 subissues just so everyone can log the time and comments, I can imagine there is a fair amount of code to rework to achieve this but the concept is not difficult and if you think outside of just bug solving programmer tasks (even then we'll assign 2+ programmers to design a schema or testing) then you'll realise it's needed.

This is a major feature that we are looking for. Can we get some official word on if this is something we can get added to a future release?

Ken!

You don't need to have the issue assigned to be able to comment and log time to it.

I would suggest that you use a workflow state to indicate those issues that a whole group is responsible to, and to add a public filter for them to find those issues easily.

I just want to see if this has a simpler solution until we get some group-assignments.

/T

Thomas Pihl wrote:

Ken!

You don't need to have the issue assigned to be able to comment and log time to it.

You don't but it makes things tie together much better, if you go to log time the task will appear on your list, if I look into the task I'll be able to see who it's assigned to rather than just a group name, you don't want to create a new group every time you have a different combination of people assigned to a task... unless you could make this group thing automatic, if you add (rather than switch to) a second user to a task perhaps the behaviour should be to create a usergroup user behind the scenes?

I realise soving this issue is not a small fix and I think perhaps looking for a small fix solution maybe the wrong thing to do, I see it as quite a major feature that deserves a proper implementation.

+1

We often have the case that I have to assign an issue to several users because they have to work together to fix it. This could be solved with sub-issues too, but it would fit together much nicer that way.

One of our customers started using the new watch-thingy for this. The person responsible got it assigned, the rest got it by watch (registred when creating issues). That way all got it in the own view, resposible under assigned, participants under watching and all got emails.

Works for us until we have some group assignments and/or subtasks.

/T

• In case of trouble, who is responsible? A, B or C? for now, it's absolutely clear who is responsible for each phase of ticket lifetime
• In case that A will finish his portion of work - he probably close the ticket or set state to something like "Resolved". But what about B and C?

Any ideas?

btw: I'm not so big fan of multiple user assigment.

+1

I also would like to assign a single task to multiple people.
What about creating a new tracker type to help address this problem?
For example, when I want my entire staff review something, I create a Tracker type called "Review Task" or "Team Task" This special tracker type is always going to have multiple people assigned to it.
Would that make coding this feature into the base redmine product more feasible?

At any rate, is there any update on this topic by the redmine team to relate to the group?
....and thx for the great product. I am a new user, and am very pleased with the power and simplicity of redmine.

+1

I really agree on this feature request. Let's take a bug report for instance. That would be nice if it could be automatically assigned to a group of developers (developers working on the given project). They will all receive the notification and one can take the task for himself once he gets time for this. It will become kind of a queue. See what i mean?
Cheers

Maxim Krušina wrote:

Hi there, have anyone idea, how to solve status changes, when ticket will be assigned to more than one user?
For example: you'll assign task to users A, B, C... so all users should work on the same ticket.

• In case of trouble, who is responsible? A, B or C? for now, it's absolutely clear who is responsible for each phase of ticket lifetime
• In case that A will finish his portion of work - he probably close the ticket or set state to something like "Resolved". But what about B and C?

Any ideas?

btw: I'm not so big fan of multiple user assigment.

I'm not really thinking about multiple user assigment. It is more about user groups that will be notified about a task report. The task is not assigned to anyone but is present into a group queue. One member of the queue can take the task for himself.

This seems like it would really create a mess of things. Each issue needs to have a single owner, so it's clear who is responsible. Some of the examples given could be handled by just adding additional people as Watchers. I think if you find yourself wanting to have multiple people working on an issue, you're probably defining the issue too broadly. Someone brought up documentation as an example: perhaps documentation should be a subproject to which those people are assigned, and then they can grab unassigned tasks from that subproject's tracker.

Guys,

I have created a plugin emailing specified email addresses when a new issue is created.

I believe it might be sufficient to solve this issue for some of you.

It is not meant to assign the issue to a group of users, but to email many users or a distribution list upon issue creation (and only at that time). People will still have to triage the issue properly.

see http://www.redmine.org/boards/3/topics/7716 for more explanation.

Any progress with this issue? (Possible option would be to configure this option for each project in the administration panel).

João Saleiro wrote:

Why:

In some teams, there are several workers with the ability to solve a specific task. It would be preferable to assign
a task to several workers, and the first who gets available would then grab the task, setting the "being solved"
to himself.

Well... i'm +1 to this issue, but I think slight different, from above ideas. I think what João Saleiro want, could be reached by ToDo plugin( developers will see the field "What is avaliable") for example(and have anothers plugins/ideas in others comments).

Maxim Krušina wrote:

Hi there, have anyone idea, how to solve status changes, when ticket will be assigned to more than one user?

• In case of trouble, who is responsible? A, B or C? for now, it's absolutely clear who is responsible for each phase of ticket lifetime

Krušina and anothers ideas I've seen in this issue relates to: one job that people do separatedly, but I think in tasks that are responsibility of more than one person (like reports, attend a suport call, developing in pairs-both are responsible).

The only way to represent this more truly IMHO is assigning to multiple users(everyone who is equally responsible and will work together). And technically speaking, I think isn't hard to implement this feature(not sure, newbie at RoR, redmine). But it's only a matter of (Database) one-to-one relation issue X assigne by one-to-many. But involves the core of model. Is that why wasn't in the planning?

+1 for this.

We often need to assign a single issue to multiple users for input/resolution, where one or all might be able or required to resolve the issue. As others have stated, creating multiple different issues to assign to each individual person is not a satisfactory resolution, because we need to assign one same issue to multiple people, not multiple different issues each to different individuals. This is a very important issue for us and is a big drawback to using Redmine versus another tracking tool we currently use.

For those 'complaining' about this feature request, I don't really see where there is a problem. If you only want to assign an issue to one person, then only assign it to one person. There's no reason that just because you don't need or want to assign issues to multiple people that other users should be discouraged from using such a feature.

If you need to get input I recommend the Question plugin (PluginQuestion) . It allows you to request someone's input by assigning a question to them while still making it clear who is ultimately reponsible for the issue.

I don't really like the principle of an issue assigned to multiple people. I think there should be one single responsible person. If not, as others said, it can lead to problems such as lags (e.g. no one wanting to undertake the issue), nobody to write the issue updates, no named owner to shout at ;-), conflicts, etc...

However, insofar as we can assign the issue to a predefined group or persons and one of these persons can take ownership of the issue, or if each predefined group has an option to designate a group representative, then why not...

It can have some advantages and I understand it might be desired in some circumstances.

Eric

PS: regarding Redmine implementation, it should be easier to assign an issue to a group than to a list of users

Eric Voisard wrote:

I don't really like the principle of an issue assigned to multiple people. I think there should be one single responsible person. If not, as others said, it can lead to problems such as lags (e.g. no one wanting to undertake the issue), nobody to write the issue updates, no named owner to shout at ;-), conflicts, etc...

I agree and disagree. The problem here is that many people look an issue as a bug or a simple task. Unfortunately, there are many tasks in a project that go beyond this. A software project contains many tasks which involve multiple people such as project meetings, discussions, reviews, customer meetings etc. Let us take an example of a project meeting. The project manager is responsible for organizing and conducting the meeting. Each member of the project needs to present in the meeting. After the project meeting, the project manager can update the task, upload the meeting minutes and attach it to the task, and update the time-spent. The time spent in the meeting should go into the time-spent column of the member. Updating the time-spent for each user separately is pretty cumbersome even for small teams.

However, insofar as we can assign the issue to a predefined group or persons

In fact, the tasks that were mentioned above are not really user tasks but group tasks. A project meeting involves the whole project team, a design review may involve the whole design group, a customer meeting may involve the whole support team, etc. For each task, we have only one output, a single meeting minutes not independent documents for each member. The task is not assigned to a user, but assigned to the whole group. The task involves the participation from all the people in the group. However, it should have one person who is responsible to organize the task and update the issue.

In summary, I would like to see the following functionality in the redmine.
a) Create user groups
b) Create a group task
c) Assign a user group to the group task and assign a owner
c) When spent-time is added to a group task, it should get reflected for each user in the group.

I know the scope of this is completely different from what is being talked here, but I believe this will help in putting down some requirements where tasks are assigned to groups.

Mohan Varma wrote:

In fact, the tasks that were mentioned above are not really user tasks but group tasks. A project meeting involves the whole project team, a design review may involve the whole design group, a customer meeting may involve the whole support team, etc. For each task, we have only one output, a single meeting minutes not independent documents for each member. The task is not assigned to a user, but assigned to the whole group. The task involves the participation from all the people in the group. However, it should have one person who is responsible to organize the task and update the issue.

In summary, I would like to see the following functionality in the redmine.
a) Create user groups
b) Create a group task
c) Assign a user group to the group task and assign a owner
c) When spent-time is added to a group task, it should get reflected for each user in the group.

I know the scope of this is completely different from what is being talked here, but I believe this will help in putting down some requirements where tasks are assigned to groups.

While assigning issues to a group would also be a much needed feature added to Redmine in addition to multi-user assignment, only allowing group assignment and not multi-user assignment only solves part of the problem. (Also, I've seen there already exist separate feature requests for such a 'group assign' feature)

I can have multiple groups, say a 'QA' group and 'Development' group, but what if I need to assign a single issue to users from both groups, but not all the users in both groups? Then either I go back to the original problem whereby I have to create duplicate issues for multiple people which really should only be one issue, or I choose and assign it to just one of the people I want to assign it rather than all, or I assign it to the QA and Development groups (if this were possible) thus adding many more people to the issue than are needed (and of course that also assumes you would be able to assign to multiple groups and not just one!).

In a nutshell, I think User groups/group assignment would be very handy, but it still is not a sufficient resolution to fulfill this feature request IMO.

As I said above, different people/companies have different workflows. I don't see any reason why allowing issues to be assigned to multiple users would hinder anyone who wants to only assign to one user. Just because you can doesn't mean you have to, but at least the functionality would be available to do either.

Something like this could even be enabled/disabled easily through a configuration option if people are so upset about having a multi-select box rather than a dropdown when assigning issues to users.

Users who only want one-person assignment enabled then Redmine can provide just a drop-down box for task assignment. Users who want multi-user assignment enabled then Redmine can provide a multi-select box. Everybody's happy. It really isn't that complicated to satisfy both needs (it's the backend implementation that is the more difficult side of things, but if multi-selection is a possibility then single selection is by default available).

It appears part of the divide here is caused by people trying to use the issue tracker for things that are not issues. Meetings and code reviews and customer discussions are not issues. The issue tracker is not a day planner. That said, a day planner or calendar would be a very nice feature to have, and I'd happily use it if it was added. I just think it needs to be separate from the issue tracker, either as a plugin or a separate tab. Keeping them separated with clearly defined goals will lead to both the issue tracker and any calendar feature being better than if they were mashed together.

Brad Mace wrote:

It appears part of the divide here is caused by people trying to use the issue tracker for things that are not issues. Meetings and code reviews and customer discussions are not issues. The issue tracker is not a day planner. That said, a day planner or calendar would be a very nice feature to have, and I'd happily use it if it was added. I just think it needs to be separate from the issue tracker, either as a plugin or a separate tab. Keeping them separated with clearly defined goals will lead to both the issue tracker and any calendar feature being better than if they were mashed together.

I absolutely disagree.

What I'm talking about are in fact issues - in my usage case this typically involves software bugs (we can't use redmine for bug tracking because of several missing features, this being one of them although we do use redmine for other things). Most of the time I agree - issues are and should be assigned to only one person, and that person is the only person who can and should be able to move the issue forward from it's current state.

However, it is very often the situation, at least in our workflow, that a single issue needs to be assigned to multiple different people in order to move forward. This does not necessarily mean that every single person it is assigned to must accomplish something for it to move forward (which would really be subtasks of the main issue); rather, that one or more of them can or must provide input for it to move forward (although not all may be required for progress), or because at a moment in time an issue might change from being a single person's responsibility into a 'group' responsibility (which might not necessarily be defined by an entire 'group' of people, but only a small subset of several people who may be from one or more 'groups' as has been described in this thread above) or temporary discussion topic, after which time it might then be compressed back into being assigned to only a single person. There are many different reasons and needs that can arise which facilitate the need to assign an issue to more than one person.

Perhaps our workflow is atypical of others, but it seems like quite a few people share this desire so maybe it is not so 'atypical'. I think the problem here is that some people are stuck thinking that there is only one acceptable workflow (i.e. only ever assigning an issue to a single user at one time) and that is the only workflow that should exist. Given the nature of the many plugins and features available in Redmine, it seems to me that Redmine should be flexible enough to accommodate multiple workflows, including whether a user should want to do something as simple as assigning an issue to more than one user.

Additionally, as I stated in my previous post, adding the ability to assign issues to multiple users does not hinder anyone who only wants to assign them to one person at a time. This is a matter of personal preference. If you prefer to assign a task to one person at a time, then do so. If you desire to assign a task to multiple people then you should be able to also (if it is implemented).

In a relatively small development environment, creating many different tasks and/or subtasks for something which could easily be contained within a single issue falls into the category, in my mind, of 'micromanaging', and would actually cost more time managing the many separate issues we would have to create, or by using multiple different channels of communication (rather than just, say, issue comments) than if we could simply keep things streamlined and when an issue happens to branch out to include multiple different users, Redmine should be flexible enough to do so.

+1 for assigning to multiple users

Not everyone works in the same way. The tool (redmine) should be flexible enough to allow the manager/architect/leader to use it however they see fit.

I have led projects that have one-person-one-task, pair-programming (two people one task), teams (multiple people, one leader), and various combinations thereof.

I also run two Redmine sites now, one for myself and one for my client. One of those sites lists only summary high-level tasks that are most often managed by a team of people. The tasks are assigned to a team (multiple people) for many reasons, one of which is that the "point person" may be out on vacation, sick, etc. and then the next person in line picks up the work. As a manager I don't care WHO leads the team, just that the team works together and gets the job done. It allows them to self-organize and self manage.

Bottom line - don't force your issue management ideals on other people. Allow the system to assign tasks to one person or multiple people. You can decide which way to use it.

Want to ENFORCE a specific method? Then simply add a "Multiple User Assignments: [ ] enabled" checkbox on the settings panel.

Lets be civil here, everyone has different ways of running projects and workflows. It would be nice to accommodate every workflow and every option but there are only so many hours in the day to code. I personally don't have any use for this feature (I only have 1 person in my development company) but I can see some valid points in having this as an option.

If someone can provide a complete and tested patch for this feature with the option to turn it on/off, then I'd be happy to review it.

+1

This would be one of the reasons for us to not be able to use Redmine for bug tracking. User groups would probably be an agreeable workaround. An assignment queue would not.

I can vibe with Tim's requirements. We run an highly active redmine userbase that varies between 20 - 50 people at any time. We simply can't use redmine to coordinate non-deliverable based tasks at the moment as the system is not configured to handle it well.

The question at hand is - what merits being an issue, and how do we support it? Upon consideration, I would suggestion that any time you need a user to log their time on something you want to be able to track, it merits being an issue.

Tim mentions meetings. I would love to know more about our meeting overhead and manage it better. We have a consistent issue with users not knowing where to clock meeting time among other types of non development tasks. Most often, they just clock anywhere they feel like it against some arbitrary issue. Which is ok for project level time tracking but for issue level accountability is just silly. We have tried creating tasks with generic names used just for clocking and then assigning them to an arbitrary person (Like "Clock Meeting time here"). Everyone then has to hunt it down to clock against it. Basically what we have right now does not support this particular need.

Now - multiple user assignment. Personally I dislike it quite a bit. We have 4 cultural pillars in our company and the most important one to me is accountability. The core value of redmine is user accountability and multiple assignments lessens that. Perhaps a creator vs owner vs assignees distinction might help but I am not in love with that either (I could probably accept it though).

I would like to discuss this with Peter and Eric Davis and get back to you all. This is definitely a problem worth tackling as resolving it will help mature the value of redmine. As with all such things, it will probably be a very simple change with massive impact.

+1

I thoroughly disagree with Brad Mace's note above. I and thousands of other people at multiple telecom equipment manufacturers have used a variant of Scrum since before it was called Scrum. This school of thought might have been derived from ideology promulgated by a consulting firm named Michael Fagan Associates, starting in the early 1990s, apparently through Motorola and then spreading to other telecom equipment manufacturers that had contact with Motorola (either via official business or via outside-of-work employee contact). In short, Redmine (or ClearQuest or DevTrack) should become the primary place that each employee goes to receive assignments for units of work that are to be institutionalized as a core asset or procedure of the company or open-source project that can be enhanced henceforth or that can suffer problems. Attending a status meeting or errands on a to-do list fall far below this threshold. Conversely, every change to a repository's source code or to any infrastructure and every assignment from the boss to prepare a presentation to an audience is likely something that should be retained for posterity in the company and thus is a unit of work that should be tracked via the process described below. As shown below, multi-assignee defect reports in a defect-tracking system (DTS) is not merely some annoying little featurette by some unwashed oddballs. No, it is the feature that is a transformative gateway to separate the men from the boys (or the girls from the women) among DTSes.

First off, (and a trivial point of agreement with Brad Mace's "an issue is not") we never use the term "issue", we use the term defect. A "bug" is a defect, because the product does not currently meet customer need/expectation. The lack of a "new feature" (usually called an "enhancement") is a defect, because the product does not currently meet customer need/expectation. Regarding the joke "Is it a bug or is it a feature?" Who cares, it is a defect! [In the case that the defect is in fact a useful feature to some people, but a flaw to other people, then the implied request for enhancement that is the intersection of these two groups of customers is that the product lacks some sort of tunability to allow these two groups to self-select themselves into two different (micro-)personalities of the product.] We reserve "issue" for the psychological definition: some sort of mental illness. :-) Thus, I will not use "issue". We view Redmine as a DTS, a defect-tracking system.

Second, in this school of thought, every defect forms a unit of work that shall change the repository for the better. Another trivial point of agreement with Brad Mace is that a meetings and day planners' to-do lists are not defects, because they (in general) do not affect the repository. Conversely, each collection of related defective behaviors (not each line/block of defective code) found in a code review is by definition a defect, just the same as if a customer had called in to the tech-support department, and just the same as if the testers had found it experientially. Obviously, the code review as a meeting is not a defect in the DTS, but each set of causes that together conspire to cause a crash or a misbehavior or a maintenance difficulty shall beget a defect report in the DTS.

Third, in this school of thought, defects that are not likely to be expansive (e.g., hey, the software crashed when I did this; hey, I would like a new field added) is typically assigned (initially) to a single person. Either 1) that one person rectifies the defect (i.e., fixes the small bug or designs the new little feature) or 2) the person investigates and then updates the defect report in the DTS to document the expansiveness that will likely require a team of people to be assembled dynamically, combining various disciplines of expertise. The defect is then assigned to management or the leader of the group to prioritize this nontrivial defect into the group's workflow & priorities & goals. At some point, this manager/leader/director assigns the defect to a dynamically-assembled scrum of people, which we called a "cross-functional team" (XFT) before the popular emergence of the scrum methodology. This scrum/XFT might or might not include the original assessor/investigator at all (either because of human-resource availability or due to having lesser expertise than what is needed). This scrum will have a scrum-master assigned from among the multiple members of the scrum, either up front or by consensus among the scrum members after they find out that they have been assembled or even changing over time if the scrum is assembled for weeks or months for a major unit of work. This scrum-master is an engineer (or technical writer for customer documentation or executive if a defect in the company's operations/structure itself or so forth) who is working on rectifying the defect as yet another scrum member, not a dictator and is not pure administrative overhead.

Fourth, as mentioned in some notes above, having a defect assigned to multiple people can easily lead to lack of responsibility/accountability/activity or duplication of effort, either of which might be intentional or accidental, because the left hand does not know what the right hand is doing. Hence, the defect report in the DTS calls out the scrum-master to use Scrum techniques to assure that this lack does not occur, because the scrum-master at least (and if operating correctly, the entire scrum) knows who is doing what right now within the scrum.

Fifth, either the manager/leader/director/scrum-master does the following up front or the members of the scrum do the following incrementally as needed over time. When a defect (either bug or new feature) is complicated enough to require more than one person, it is highly likely that this is an umbrella defect that—as investigation or rectification proceeds—subordinate defects will be uncovered, such as someone needs to revise the database schema, someone needs to update the GUI, and someone needs to revise the communication protocol. In this example, the umbrella/parent/master defect report will then have 3 new child/slave subdefect reports created underneath it. [The master-servant terms mesh together, but are not politically correct nowadays, but the parent-child terminology might also get re-used for the case of duplicate defect reports for the same defect or for multiple quite-different symptomatic defect reports for the same underlying root-cause defect, so there exists a need for a term to separate 1) the umbrella defect report that houses heterogenous subunits of work from 2) the duplication defect report that houses homogenous-copy defect reports that will be rectified by the same root-cause unit of work.]

As we see, assigning a defect report to multiple people implies something that resembles a scrum (even if the shop does not admit to using the scrum methodology, or uses a nontextbook variant of scrum). As we see, this scrum is multiple people because there is multiple subunits of work to do. As we see, these subunits of work are themselves subdefects that each require their own subdefect reports in the DTS. As we see, the umbrella defect report assigned to multiple people is usually actually a tree of units of work that can each be comprised of their own respective units of work recursively. As we see, the umbrella defect report that tracks the subdefect reports' subunits of work.

I have seen this form of scrum scale to nearly 10,000 people at 2 different telecom equipment manufacturers and to over 300 at a start-up telecom equipment manufacturer. A large company of tens of thousands of people is nicely decomposed into thousands of dynamically-assembled scrums that resemble bees in a beehive aggressively doing their thing on millions of lines of shared code. Scrum assemblages come & go for each defect report in the DTS, i.e., for each unit of work. It was based on a highly-customized extrapolation of Atria's/PureAtria's/Rational's/IBM's ClearCase-DDTS (in the 1990s) or ClearQuest (since the late 1990s) or of TechExcel's DevTrack. (By the way, the DevTrack-Perforce customization & integration seemed much easier & smoother to accomplish by a single temporarily-borrowed engineer than the DDTS-ClearCase and ClearQuest-ClearCase customizations & integrations by a department of specialists.) I have evaluated over 20 DTS/bug-tracking/issue-tracking/support-ticketing systems. It appears that Redmine is the closest open-source one to "getting it" regarding this school of thought. Other than DDTS, ClearQuest, and DevTrack, the only other DTS that appears to fully "get it" is Microsoft's internal Raid, which has been reworked into the DTS within Visual Studio Team Foundation, based on the description in The practical guide to defect prevention by McDonald, et. al., and How we test software at Microsoft by Page, et. al and another book that incrementally describes bits & pieces of Raid that I cannot lay my hands on at the moment.

I disagree with Eric Voisard's P.S. above. As you can observe in my write-up above, the collection of people may be quite different per defect report. Having to overtly define a new named group prior to starting to add a fresh multi-assignee defect report is practically useless. Based on my usage of DTSes that had this ability over the past 16 years, the ability to determine the scrums membership needs to be quite dynamic and incremental over the period of days, weeks, or months during which the defect is being rectified. For 5000 multi-assignee bugs over the years, why should the DTS be cluttered with up to 5000 different named groups of dynamic assemblages of people? Groups should be for collectives that resemble departments in a company or permanent/semipermantent teams in companies or in open-source projects.

I agree strongly with Thomas Pihl's demarcation of two different flavors of multi-assignee defect reports. There exists a huge difference between A) the scrum that I describe above who are assembled to collaborate & accomplish what is impractical for one person to accomplish alone versus B) a pool of people who volunteer to accomplish a small unit of work that interests them.

The feedback on this ticket looks to be clearly in favor of having multiple assignees to a ticket, instead of groups. Who wants to create a group every time there are multiple people responsible for working an an issue through to completion? Not I.

I can just see the group names now. John Smith + Developer 1. John Smith + Developer 2. Daniel Millers feedback accurately addresses this in detail.

+1 for putting this feature back on the table.

Patrick Cummins wrote:

+1 for putting this feature back on the table.

I have tagged this for a developer decision, but I wouldn't hold my breath. Add to the arguments I already cited that I seem to remember JPLang commenting on non-unique assignees that he didn't want it as you loose the direct accountability.

The original request actually sounds a lot like what the Stuff To Do plugin provides (or would if it worked right for me). Perhaps redmine could incorporate similar features and allow queueing/recommending a task for multiple developers and then the first one that has time for it can assign it to themselves.

I registered here just so I can add my request for this feature. Assigning tasks to multiple users is definitely not a duplicate of the request to be able to assign tasks to groups, although I would find both useful. Redmine is a great product in many ways and I am very thankful to the developers who have gotten it to the current stage, but I hope they will not make the mistake that has killed many products, both open and closed source: the arrogance of deciding that users should adapt their workflow to the tool, rather than building a tool that fit the user's needs. While I appreciate the comments some people have made about why being able to assign an issue to multiple users is a bad idea from an accountability perspective, that does not change the fact that many people would find this ability extremely useful. In fact, the lack of it makes Redmine really cumbersome for me to use.

+1
I'm absolutely for assigning multiple persons not group. It would not be intuitive to create a group and assign the task for it, specially that most of the tasks are assigned to multiple users, purely ad-hoc.

+1
I would also like to see this functionality introduced.

Patrick Cummins wrote:

The feedback on this ticket looks to be clearly in favor of having multiple assignees to a ticket, instead of groups. Who wants to create a group every time there are multiple people responsible for working an an issue through to completion? Not I.

IMHO both feature would be really useful:

• Assigning an issue to a group (so every user in such group can manage it).
• Assigning an issue to more than one user (or group).

I've just noticed this one - but I am wondering what the real problem is. We also have the situation where I need certain people to comment or even possibly update on an issue. In that case, I add them as a "Watcher" and that's it. But the ticket remains assigned to one, and only one person at a time. In my experience, assigning things to multiple people leads to nobody doing anything "because the other one's doing it too" - but without explicitly saying so.

Having just one assignee each time also allows for nice workflows, e.g. the developer updating the status and then reassigning it to the next in line. Much more efficient, clear and trackable, I think.

Would it be an good idea if an issue could be assinged to role? So an issue could be assigned to 'developers' or 'testers'.

I think this is not the best solution, but this might be realized more easily. Not sure.

+1

+1 This would really be useful

+1, this is a great idea

+1 This Is vital feature ! Why it's still note added to roadmap

+1 Very important feature.. wonder if someone could work on it..

Looks like this is a big change, that's why it is not getting picked..

+1 Please reopen this issue. This is most definitely NOT addressed by the ability to assign issues to groups. As others have said, if you don't like the feature, don't use it. In my organization, it's clearly needed. Not everybody uses the same development process, and this is requested often enough, I don't really understand why this is even controversial.

One more thing: here's an idea on how to implement this feature. Since it's already possible to assign issues to groups, you could have ad-hoc groups that are hidden from the UI, but use whatever machinery is already in place to assign to groups. This could potentially lead to having one hidden group per issue, but--so what? You would need to distinguish this case form assigning to an existing group, because you want to be able to change the assignees for an issue without affecting other issues, as would happen if you used preexisting groups (another reason, BTW, that assigning to groups doesn't actually cover this).

+1 We're switching to Redmine from ClockingIT where it was possible to assign issue to multiple users. And it was a very useful feature.

I work in a non profit organization. In the my organization, we have different departments/sections under a director. Directory opens up an issue that will be handled by the organization. An issue usually involves multiple sections/departments. One department always becomes what we call coordinator. Coordinator has the main responsibility about the issue. The others will do their parts but the coordinator will track the issue throuhout whole lifecycle until its completion. Now we are trying to achieve this via one assignee as the coordinator and the watchers as the others or under main issue for the coordinator, we place multiple sub issues for each department/section.
This is cumbersome not directly what we need.
We need multiple assigments, if possible a field to mark who is overall responsible.

Do not post to closed issue.
Current duplicate issue is #12579.

Please provide this solutions, it will be very helpful to us.

We have to assign a single task to multiple users, but not able to do so.

+1

+1

+1 !!!

+1

Do not post to closed duplicate issue.

Current open issue is #12579.