Ability to keep remaining team members as reviewers after one team member starts a review

[nieuwsma]

Presently, if I add a team as a reviewer on a pull request, the first person from that team to start a review does so "on behalf of" the team, and the remaining team members no longer see that their review is requested on that pull request.

I can see that this may be useful in some cases, however in our company's case, we require at least one review from a team member, but encourage other team members to review also. Therefore, we would like a setting for all team members to remain on the PR as reviewers. I could see this being a repo-level or org-level setting.

Our workaround has been to list each individual in the CODEOWNERS files, however this is suboptimal because when a team changes, we will need to update the list of team members in multiple CODEOWNERS files, instead of in the central configuration for that team.

TAKEN from: isaacs/github#1211

a LOT of people would really like this 'feature' fixed. This makes management of PRs email driven rather than github UI driven.

[alexander-anderson-salesforce]

This is on the first page of all feature requests when sorting by TOP. Doesn't seem like it is getting surfaced/noticed. My team would also love to have this feature.

[simplisamtwining]

This is also a major annoyance when trying to find PRs that you've been tagged in on our team. Insight into PRs that have a team tagged that someone has touched is aggravatingly low.

[aitkin-dn]

So there is no solution to this issue currently?
Our team was so happy that we don't need to add everyone manually when we discovered this group option, but now we understand we can't really use it as we did the previous review requests so that everyone will be informed even if someone reviewed :\

[ay-azara]

@shyamsundar It doesn't specifically say in the docs but the Github website, for me, shows me up to 7 under Team->Settings->Code Review. Since you said server, I assume you're self-hosting, so maybe it is not up to date with the latest version available? That's just speculation on my part. SnailedIt has a screenshot further down of what it should look like to you.

[Snailedlt]

For future reference: The screenshot can be found here: https://github.com/orgs/community/discussions/5289#discussioncomment-7777105

[shyamsundar]

Thanks @Snailedlt. It looks like our server is not on the latest release. I only see 3 in the dropdown and I also don't see the 'Scheduled reminders' option that's in the screenshot.

[shyamsundar]

@Snailedlt, @ay-azara any idea from which version this setting allows 7 instead of 3?

[Snailedlt]

Nope, no idea :/

[samibeyoglu]

This is really annoyance! Every time I comment on a PR, my team gets removed from the reviewers and I have to re-add it.

[jeffhelps]

This works fine for single approver repos, but clearly doesn't when you have 2 (or more) approvers needed, would like to see this get fixed

[simplisamtwining]

For anyone else vexxed by this:

A coworker filled me in on the workaround by configuring auto-assignment. When your team is assigned it'll individually add members of your team.

https://docs.github.com/en/organizations/organizing-members-into-teams/managing-code-review-settings-for-your-team#configuring-auto-assignment

[michaelheyman]

This workaround only solves the problem stated in this thread for teams with up to 3 members, because there's a limit of 3 members that can be auto-assigned to review.

[hubbcaps]

+1, this is desperately needed for repos that require more than 2 reviewers. PRs end up collecting dust due to not being visible to the larger team after someone hops on an initial review.

[Snailedlt]

+1.
I had no idea it even was like this. Imo, the default behavior should be that all reviewers stay reviewers unless you remove them as reviewers.

[andreas-hakansson-ingka]

+1, we also require at least 2 reviewers and created a team to help assign the correct people. Our expected behavior wasn't that everyone else would be removed as soon as a single developer performed a review. As the bare minimum, make this behavior a branch protection setting so we can choose

[drewnichols]

+1 I would also like to be able to add my entire team to the PR more easily. Having the team removed after 1-3 people review the PR is not helpful.

[melvincwng]

+1 agree on this feature request. Hope to see it being implemented in the near future 👍🏻

[max-pi]

I think default behavior should be that team stays assigned as reviewers, as this more closely matches behavior when you specify specific reviewers. Or ideally this should be a toggle setting for the team

[ClementHoang-at]

👍 Would like this so that the flow can less email driven.

[kemallette]

This was a surprising discovery for our team. Please address.

[jzisser9]

Our team was so excited when we discovered this feature, but the fact it de-selects the group when one person responds to the PR is a huge deal-breaker for us. Please address this - this is an amazing feature, especially for larger teams, hampered by one small aspect of its design.

[pawelantosik]

+1

[c0dev0id]

+1
we have groups of 20-30 people and reviews are optional. We want everyone of the group to be able to review. Please give us an option to keep the group in the reviewer list. (Github Enterprise in our case...)

[aslafy-z]

A workaround is to reference every individual users into the CODEOWNER file that will then configure automatic reviewers assignment. However, adding a group instead in this CODEOWNER file falls on the OP issue.

I don't like this solution but it does the thing in my little team of 5 as of today.

[RubenGamarrarodriguez-tomtom]

A workaround is to reference every individual users into the CODEOWNER file that will then configure automatic reviewers assignment. However, adding a group instead in this CODEOWNER file falls on the OP issue.

I think that is not idea, every time one member joins or leave the team it would require some automation to update, review and merge the codeowners in the 40+ repos that a team maintains and operate

[Snailedlt]

If someone makes that automation script, please do share so the rest can use and contribute to it :)

[aaron-oxford]

+1

Now that I've been added to the core review team group, I can't just give an individual approval any more. I'm signing off for the whole team.

[federico-caimi-rally]

+1

[cpinkerton-kpler]

The default behaviour here is too opinionated - it needs to change or allow some configuration of the behaviour

[jacktoussaint]

+1

[Joker368]

Not sure if something like this has been mentioned yet but for anyone who wants a work around for this you can try the following.

Example for a team with 9 engineers:
Create two children teams under your main github engineering team. (It doesn't have to be a child team but I found it's easier to do it this way for organization)

XYZCodeReviewTeam1 - Add 7 members (the max number for code review auto assignments per team)
XYZCodeReviewTeam2 - Add 2 members

Under the Code Review settings for each of these teams:
Enable auto assignment
Set "How many team members should be assigned to review?" to the max value (atm that is 7 -- meaning each child team can support up to 7 engineers and hence the reason for splitting the 9 engineers between a team of 7 and a team of 2).

As new engineers join your team you can add them to XYZCodeReviewTeam2 until you reach the limit of 7 before creating XYZCodeReviewTeam3 and so on and so forth.

The last caveat is that you must update the .github/CODEOWNERS file for every repo to include each of these teams as a code owner. Now every time you open a PR these two teams will be added automatically and then (because of "Enable auto assignment") the individual engineers will be auto assigned. Github currently supports up to 100 reviewers so this should work for most scenarios.

We just implemented this and it's working great. Feel free to reach out to me if you need assistance or want to discuss further.

[jorhett]

Not sure if something like this has been mentioned yet but for anyone who wants a work around for this

insert lots of manual team editing

This is really not useful for any org large enough to have more than 7 members 👎 I can't think of a single org I work with (open source or not) that doesn't have SSO that defines the teams externally. No, nobody is going to spend time in an IDP hacking up teams to balance them correctly.

If we had that kind of time, we should migrate to Gitlab who allows us the freedom to define the rules as we desire.

[superwiss]

+1

Our ground rule for code reviews is that more than one person participates in the review activity.
However, because of this limitation, we got a problems.
I would like to see a feature or option added that would allow team members to remain reviewers even after review activity begins.
(Github Enterprise in our case...)

[NicoPampe]

+1 - not a very helpful comment other then checking if this has gotten any traction or solved. I've recently set up Team's in our company github flow for auto team assignment on PR's. It's very handy to get everyone on the PR's, but then everyone is lost once a single person reviews it, the Team addition is gone.

[rngadam]

We've got our pull requests for one repository set to at least three reviewers and a Github team (all) added,

as soon as one reviewer reviews, the team is cleared out even though the requirement hasn't been fulfilled

[Snailedlt]

If you're 7 or less developers you can use a combination of these two settings under https://github.com/orgs/your_org_name/teams/your_team_name/edit/review_assignment

[gabriellamichelle]

+1 The team scheduled reminder to slack is not that useful with this existing behaviour. Keeping the team would help lots of our workflows.

[rngadam]

If you're 7 or less developers you can use a combination of these two settings under https://github.com/orgs/your_org_name/teams/your_team_name/edit/review_assignment

I can see how this can be helpful so thanks for ponting that out, but it's not exactly what we want.

• we have PR that has content relevant to the whole team
• we want to assign the PR to all
• as soon as we clear a set number of reviews (3) from anyone in the team, we can clear
• we still want others from the team to have a look beyond that

[Snailedlt]

I see. If you have multiple teams that can review the PR, but these rules only applies to one of them, then there's not currently any solution for this afaik. However if the goal is to just ensure that the PR is reviewed by 3 people before it gets merged, then you can use branch-restrictions instead:

[rngadam]

Thank you!

[Edgar-Schmidt-Horsch]

+1 We need also every assigned member of the group to look up the pull request after one other member approved on behalf of the group. Otherwise the request will be lost.

[Wicaeed]

Why why why if I have a Team that is on a PR, and GItHub picks random users in that team to add directly to the PR, if one of the users that WASN'T picked and added to the PR comes and adds their review, WHY does the whole Team now get removed the PR?!?!

Useless, confusing behavior from GitHub...

[SergeyBarskiyTyler]

+1