GitHub Community
Ability to keep remaining team members as reviewers after one team member starts a review #5289
Replies: 49 comments 25 replies
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
So there is no solution to this issue currently? |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
For future reference: The screenshot can be found here: https://github.com/orgs/community/discussions/5289#discussioncomment-7777105 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@Snailedlt, @ay-azara any idea from which version this setting allows |
Beta Was this translation helpful? Give feedback.
-
|
Nope, no idea :/ |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
+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. |
Beta Was this translation helpful? Give feedback.
-
|
+1. |
Beta Was this translation helpful? Give feedback.
-
|
+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 |
Beta Was this translation helpful? Give feedback.
-
|
+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. |
Beta Was this translation helpful? Give feedback.
-
|
+1 agree on this feature request. Hope to see it being implemented in the near future 👍🏻 |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
👍 Would like this so that the flow can less email driven. |
Beta Was this translation helpful? Give feedback.
-
|
This was a surprising discovery for our team. Please address. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
|
If someone makes that automation script, please do share so the rest can use and contribute to it :) |
Beta Was this translation helpful? Give feedback.
-
|
+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. |
Beta Was this translation helpful? Give feedback.
-
|
The default behaviour here is too opinionated - it needs to change or allow some configuration of the behaviour |
Beta Was this translation helpful? Give feedback.
-
|
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: XYZCodeReviewTeam1 - Add 7 members (the max number for code review auto assignments per team) Under the Code Review settings for each of these teams: 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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
+1 Our ground rule for code reviews is that more than one person participates in the review activity. |
Beta Was this translation helpful? Give feedback.
-
|
+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. |
Beta Was this translation helpful? Give feedback.
-
|
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
|
Beta Was this translation helpful? Give feedback.
-
|
If you're 7 or less developers you can use a combination of these two settings under |
Beta Was this translation helpful? Give feedback.
-
|
+1 The team scheduled reminder to slack is not that useful with this existing behaviour. Keeping the team would help lots of our workflows. |
Beta Was this translation helpful? Give feedback.
-
I can see how this can be helpful so thanks for ponting that out, but it's not exactly what we want.
|
Beta Was this translation helpful? Give feedback.
-
|
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: |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
+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. |
Beta Was this translation helpful? Give feedback.
-
|
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... |
Beta Was this translation helpful? Give feedback.
and others
-
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.
Beta Was this translation helpful? Give feedback.
All reactions