
Multiple assignees on Issues and Pull requests - richerlariviere
https://github.com/blog/2178-multiple-assignees-on-issues-and-pull-requests
======
awaxman11
Surprised to see so much negative feedback. I agree that clear responsibility
is important, and that adding multiple assignees when those people share
similar responsibilities could lead to the bystander effect.

I'm really excited about this feature. I feel like "If only GitHub Issues
allowed multiple assignees" comes up in conversations with colleagues at least
a couple times a month.

For context, the design (and development) team I work with uses GitHub Issues
religiously. Right now all issues that need design work are explicitly
assigned to a designer, and we use a label based workflow combined with
Codetree to help organize weekly sprints. Having multiple assignees will allow
us to explicitly assign a product manager to each of these issues w/o having
to take it out of each designer's sprint, which will help make sure all design
tasks receive feedback and move forward in a timely manner.

~~~
kwiens
Or, you could create a separate issue for designing the project and for
implementing it. Then cc the PM on both. Done!

At the end of the day, someone should be responsible for completing the issue.
Is it a PM? Assign it to them. Is it a designer? Assign it to them.

We use Codetree as well, and it's wonderful. But the key is to use small,
focused issues with a single individual accountable for each one.

~~~
awaxman11
We do create separate issues for design and development :)

IMO having an explicit assignee is more clear than cc'ing someone, and it also
makes it easier to see all issues that you're currently responsible for moving
forward. At the end of the day whatever works best for the given team is what
should be used. I don't think there is a definitively right or wrong approach.
Our current approach works quite well, and this new feature is going to make
things even easier.

------
jvehent
The best way to make sure something never gets done is to share ownership of
it.

~~~
JoshTriplett
[https://en.wikipedia.org/wiki/Diffusion_of_responsibility](https://en.wikipedia.org/wiki/Diffusion_of_responsibility)

~~~
rasz_pl
[https://en.wikipedia.org/wiki/Bystander_effect](https://en.wikipedia.org/wiki/Bystander_effect)

------
CognitiveLens
Wasn't expecting such a negative reaction to this. For Issues, the feature
isn't particularly useful to me, but for Pull Requests, it's a great way of
declaring who needs to sign off for the PR to be merged. When big features
come into PR, people where I work were reluctant to use the 'Assignee' feature
at all because it implied that the PR was already 'taken' for code review.
Now, a front end engineer can assign themselves to do the FE review and a back
end engineer can assign themselves to do the BE review, and the reviewers can
be directly seen from the PR list. Nice.

------
maffydub
Does anyone know if it's possible to disable this? For teams like mine, where
we want to have only one owner for each issue, it's meant many more clicks to
perform a reassignment operation.

------
zcam
There are many improvements needed on Issues; this one is certainly not the
first that comes to mind.

------
TearsInTheRain
Great! Now it would be cool if I could save a group so I could in one click
assign my pr's to my team instead of having to individually add each member
each time

------
phasmantistes
Assigning pull requests to multiple people is fantastic: sometimes you're
modifying a library and want the owner of that library to review your code,
but you're simultaneously modifying the clients of that library and want their
owners to review the change as well.

Assigning issues to multiple owners is a recipe for complete and utter
inaction from all parties involved.

~~~
PretzelFisch
They seem to have the idea of Assignee and interested party mixed up. Many
times two people need notifications, but I have never seen the need for two
concurrent assignees.

------
dfischer
This is bad practice for getting things done.

~~~
geuis
No, its GREAT for getting things done! I'm only interested in it for pull
requests, so that's the angle I'm coming from. I know what you mean for
regular issues though.

------
ericclemmons
I'm glad this feature is in, but it's only useful for my PRs.

For example, there was a recent PR where the owner was modeling the UI for a
feature with stubbed calls, while I was setting up the backend.

Once my work was done, he wrapped up the rest, and I was no longer needed.

We used notifications to informally say "you're still needed for this!" vs it
being part of my daily hit list.

