Page MenuHomePhabricator

Phabricator should allow multiple assignees
Closed, DeclinedPublic

Description

It should be possible add more than one people to cards where collaboration is happening - e.g. a designer and a dev, a developer and a code reviewer, a product manager and a developer.

Currently you can only add one. Please can we make this possible?

Event Timeline

Jdlrobson raised the priority of this task from to Needs Triage.
Jdlrobson updated the task description. (Show Details)
Jdlrobson added a project: Phabricator.
Jdlrobson subscribed.

I think the underlying concept is that at one point in time, one person is responsible for driving a task and that person should be identifiable (see e.g. Gerrit changesets where all reviewers might wait for another reviewer to do the review).
All involved parties on a task can be CCed and tasks can be reassigned to a different person.
Subtasks for specific steps could be created and block the main task. Or certain states of a task can be expressed via columns on project's workboards (the term "swimlane" comes to my mind but that's probably not entirely correct).

So I don't think that upstream would support this proposal without a very convincing usecase.
Are there any examples for current tasks that really should have several assignees and where existing functionality is not sufficient?

Qgil subscribed.

You can add as many people as you want as subscribers, or in the description of the task. Still, having one and only one owner of the task at a time makes sense, and as far as I can see it is aligned in how we work in our projects.

Aklapper changed the task status from Open to Stalled.Sep 19 2015, 6:33 AM
Aklapper claimed this task.

Declining as no reply to T112679#1642439. Feel free to reopen if there are specific arguments/reasons not covered.

I realize this is a lost cause, and I recognize that there are significant costs to having multiple assignees, but you asked why it the existing limits are not always sufficient, so I'll post this in case someone ever wants to think about this in the future:

The current functionality means that nearly all of tasks I need to spend time on are not listed in Phab as something that I need to spend time on. Instead, they're listed as tasks that other people need to do. That's okay for me (I already know what I'm going to do). However, I don't know whether this non-transparent situation works for other people.

As a result of this design choice, the only way for anyone to find out what my complete task list is to ask me. So if you see task assignments as a way of communicating my work plans or past progress to others (e.g., my manager), then the single-assignee system is deficient.

If you see Phab as a functional system for telling people what to do, then it's worse. When you have a task that needs to be done by two people, you cannot use Phab to put the task in both people's list of open tasks. You can only assign it to one, subscribe the other, and hope that the second one both reads the task description closely and remembers to work on it.

As for examples of tasks that might benefit from a broader notion of responsibility for a task: Even a person who does less job-sharing and collaborative work than I may occasionally encounter tasks like "Alice and Bob to make a recommendation about the widget", in situations where neither Alice nor Bob (perhaps from competing groups or from opposite sides of a sensitive situation) are meant to "own" the discussion or to have even nominally more power or control over it than the other. It's unlikely that dozens of assignees would be useful (although I could see a manager creating an assignment for all staff to perform some particular action), but it is not uncommon for two or three people to actually have equal roles in certain tasks or decisions.

Collaborating on tasks can take different forms, and this has led to different workarounds for Phab's limitations. The roles might be interchangeable (Alice and Bob each write a few sentences of a report here or there) or they might be specialized (Alice collects the data and Bob writes the description). In the specialized case, you can create subtasks; the main cost is bureaucratic overhead. In the former case, the apparent "solution" is to create near-duplicate tasks (t123, "Bob to work with Alice to write the report" and t124, "Alice to work with Bob to write the report").

Or, alternatively, we can accept the current limitations and you can decide that, if you truly need to know what I've done or what I'm planning to do, you will send me an e-mail message and wait for a reply. That truly does work for me; I'm just dubious that it works as well for anyone else. (Also, it won't pass a bus test.)

@Whatamidoing-WMF, can you provide real examples affecting to you, here in Phabricator?

I think adding the Liaisons monthly sprint tag to show that you are working on it and then updating the tasks with your comments would suffice to identify that you are working on a task, even if it is not assigned to you. Then, if these tasks are regular, you can also choose to alternate assignee with your counterpart.

At least let me stress that if the problem is "task assignments as a way of communicating my work plans or past progress", I don't think anybody is calculating work done based on task assignment, or any other calculation. Completion of team goals and individual goals plus keeping up team's core workflows is how the WMF is measuring, in combination with annual reviews.

If two people are working on a task together it would make sense to me that they both create a subtask for their part of the overall task.