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.

[himashan]

they bumped it to 7 now

[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

[SergeyBarskiyTyler]

+1

[tamnaeuth]

+1

[ttt43ttt]

+1

[zeasey-apptio]

I've noticed this behavior recently and first thought it was a bug, why is the default to remove the team?

We've recently created a dashboard dedicated to view all open code reviews for our team, implemented with a search query.
Example search:

org:MyOrg state:open type:pr team-review-requested:MyOrg/my-team-reviews

However, since "removing the team" is the default and can not be configured as disabled, it renders our dashboard pointless unless we continually add our team back on the review each time.

[robmcgee-isw]

+1 this makes the team reviewer approach useless to me

[PeterRydberg]

+1

It is very strange to remove information from an existing PR, closed or not. If the team is requested for review, it should remain that way. I should be able to do review-requested:@me or at the very least team-review-requested:ORG/TEAM even if the PR is merged.

[kevindvnetapp]

+1.

For codebase where the files are reviewed by a large number of folks, automatically removing the team review is impacting us . The workaround listed above is limited by 7 people, which does not work for our team size.

[NetAppBlueDevil]

This behavior is crazy. It says that the new intern in the team for the summer is equivalent to the senior engineer that has seen this code for 10+ years when commenting on a code review. The requirement here is more than just wanting more people, it is specifically based on the mix of people in the team and experience level. Fixing this requires simply a flag level option to wrap an if around the block of code that would remove the team from the PR. This is not a "OMG we have to re-architect the entire thing" type of request.

[Thomas-Hagen-Shipt]

This is still an ongoing issue 5 years later. We are planning to stop using the team concept in our single-team CODEOWNERS and instead list out all of the individuals across all of our projects until support for this is added.

[davilima6]

this sounds like AI and should be deleted

[yoshi-jpc]

+1

[davidwarner234]

+1. Keeping the review request visible for all team members would encourage more reviews while still satisfying the required team approval. An optional org or repo setting would be a much better solution than listing every individual in CODEOWNERS.

[aws-mengchiy]

+1

[thatsanicehat]

Still asking for this 5 years later! The ability to set the number of reviewers would be ideal so that If I have a team of 15, I don't need to tag them individually but can still have that team's tag disappear after n members approve if I want.

[thescientist13]

Just coming in to say this a pretty big bummer after having just streamlined our project's to use teams for CODEOWNERS 😕

[robmcgee-isw]

Thanks for saving me the time. I thought that would workaround this problem.