Preview Feedback: Require review from specific team rule

[patrick-knight]

Required review by specific teams now available as a preview feature in rulesets

Take control of your protected branches! You can now use rulesets to require approvals from specific teams for changes to specific files and folders.

What's new

• Protect critical code by enforcing strict reviews for your most sensitive files.
• Scale your policies across any repository, organization, or your entire enterprise.
• Target specific paths and require a set number of reviews from specified teams.

Rulesets vs. CODEOWNERS

While CODEOWNERS is great for defining ownership, this new ruleset focuses on policy enforcement. It makes it simple to require specific approvals on sensitive branches and critical code paths, all while scaling seamlessly across your enterprise.

This new rule is designed to augment CODEOWNER files but not replace them. The CODEOWNERS files will continue to be the way to manage ownership, support individuals as reviewers, and request reviews even if not required.

---

🌟 Leave a comment!

What do you think? Join the discussion and leave your feedback below!

[AlexCK-STFC]

Great in theory, but it doesn't seem negation works right now, when it says it uses the same syntax as .gitignore files!

I.e. this does not work:

**
!safefile.txt
!/safe-folder/**
!/safe-folder/

PRs are still blocked + require specific approval if a negated/allowed file is edited.

[sergei-startsev]

@patrick-knight is there any timeline for negations support? It's a must have feature for any large-scale project.

[patrick-knight]

Not an exact date yet, but it is on the requirements plan for us to get this rule to general availability during the first quarter 2026.

[patrick-knight]

We are looking to have negation support available Feb 10 and will follow the ! pattern from .gitignore.

[sergei-startsev]

@patrick-knight any updates on negations support?

[patrick-knight]

Give it a whirl should be live now.

[AndreasPetersen]

I haven't had the chance to try this feature yet, since it's still in preview, and I would need to ask my organization manager to enable it. Before asking them, I have a question though. It seems unclear from the announcement what the exact behaviour is for pull requests. Is it similar to how CODEOWNERS work?

Specifically I'm curious if this feature addresses https://github.com/orgs/community/discussions/178776. We would really like to be able to assign/require a team as reviewer, so that the team is automatically added to any PR as specified by the ruleset, but keep the team there as individual members add reviews to the PR.

[patrick-knight]

Yes this is similar to Codeowners in that the team will be added to the Reviewers sections of the PR.

I'm not certain about the second part of the question of the link shared is for this discussion but I presume it references something else.

[stevehipwell]

@patrick-knight should this be supported in the REST API?

[patrick-knight]

API docs for REST and GraphQL are coming soon.

[patrick-knight]

REST and GraphQL docs have be update to reflect this new rule.

[bkd365]

Great feature, our team is migrating from Azure DevOps and this covers a gap that codeowners didn't quite fill.

One issue is that for repository rulesets, I am only able to setup teams that have been given direct access to the repository. Teams with organization access to all repositories are not selectable. This limitation isn't there for rulesets created at the organization level.

[patrick-knight]

You can declare them on org rulesets, but are only enforced if the team has direct repo access, much like how bypass lists in repos allow you to define any bypasser even if doesn't have access to act on it.

This is a limitation currently in the pull request experience on the location teams can be sourced from.

[audunsolemdal]

Hey @patrick-knight - as you can see I've been interested in this for quite a while. After doing some testing, I think the current preview has potential but has some limitations compared to require review from codeowners which my org is currently relying on.

Specifically there are some cases where we require an approval for some paths for either team A or team B in CODEOWNERS
*.md @myorg/admin-team @myorg/project-team
I believe this is not possible with just using the new functionality(?) without CODEOWNERS - Hard for me to test as I don't have accounts to review/verify

Also the require review from specific team functionality is still one-dimensional in a sense. Ideally - say that I am a member of the team @myorg/admin-team I would like to have 0 required reviewers for **.tf files for this specific team. While members of other teams, e.g. @myorg/project-team should require an approval to make changes to **.tf files.

Extending on this - the functionality is still locked within Require a pull request before merging. There may be cases we would also like the option to bypass creating a PR entirely. I know this is a symptom of a larger issue, and I have a problem with this behavior in general, as it also causes issues in other contexts. Simply put - I think the logic for the checkbox Require a pull request before merging should be far more flexible than a true/false checkbox.

[patrick-knight]

The starting goals for us were around introducing branch specific reviewers which is hard to accomplish with CODEOWNERS, and add in discrete team based mandatory reviews.

The reviews for teams are ANDs unless you create a parent team that houses both sub-teams than the review can be satisfied by member of the broader team.

You can add multiple teams for the same paths, with different review requirements, so that should be doable.

We did recently move the CCR rule out of the PR rule into its own rule. I am curious to understand the desire to decouple review requirements from requiring pull requests

In the end this is why we launch previews to get feedback like this, so thanks for sharing.

[HughGrovesArup]

There doesn't seem to be any UI on the PR itself showing that this review is needed. Is this expected behaviour, or is my ruleset not being applied appropriately?

[patrick-knight]

I suspect there might be something misconfigured, as the reviews should show in the review section of the PR as well as inline in the merge box.

[HughGrovesArup]

I have reviewed and on new PRs the UI is showing, but on PRs that pre-date the rule being applied the UI is not showing.

[HughGrovesArup]

New PR:

Old PR:

[patrick-knight]

This is expected behavior when editing rulesets while a PR is open. If there is new activity on the PR it will re-run rules to evaluate the new set of requirements.

[brendengoetz]

What do we need to do to be able to test this preview feature in our organization or repo? I am not seeing it available to enable/disable in my account under the "Feature preview dialog," nor do I see I way to request access to a technical preview.... I am a repo admin, but not an org admin if that matters. We very much are looking forward to this feature. Thanks!

[patrick-knight]

Hey @brendengoetz,

No need to request or enable this preview as it is available everywhere as a new option as part of the existing pull request rule.

[brendengoetz]

I see it now -- thank you!

[dustinbrooks]

@patrick-knight While not having the same functionality, we could control some exclusion logic with the order of patterns in CODEOWNERS, is that still true? Here is my scenario:
Team1 is responsible for Directory1 and everything in it.
Team2 and Team3 are responsible for everything else in the repo except Directory1.

In CODEOWNERS I just had Team2 and Team3 at the top with the "*": * @ORG/Team2 @ORG/Team3
And then the last line with /Directory1/ @ORG/Team1 took precedent and didn't include the other teams.

[dustinbrooks]

I was able to do a quick test just adding the rule and 3 reviewer teams.

For a change in Directory1 it added all 3 teams.

I would love to be able to just add Team2 and 3 with a * and exclude !/Directory1/ so we don't have to maintain an explicit inclusion list for everything, that would also allow a loophole I think for a new directory to get added and not require approvers.

[patrick-knight]

Thanks for the investigation and note, we've gotten the feedback on supporting exclusion/negations and will investigate feasible of that as part of this rule.

[patrick-knight]

We're aiming to have ! negation support on Feb 10th.

[Ant0wan]

Hi all :-)
I have been digging for few days now, but I cannot find any Terraform implementation of this. Is there a way to achieve it with IaC or gh-cli atm in order to automate it ?
Best,

[NPastorale]

Is there any timeline defined for having this added to the provider?

[patrick-knight]

There is not at this time.

[stevehipwell]

@NPastorale I'd suggest you open an issue on the TF provider repo to request support for this.

[jackmtpt]

integrations/terraform-provider-github#3081 i've made one here since it wasn't done before

[stevehipwell]

This will likely make it into the next TF provider minor release and there is already a draft PR.

[gabrieltaylor]

Love this feature. We've been looking for a way to decouple ownership from review required.

I would like to humbly request an increase to the limit of 15 filter patterns per required reviewer. We're working with a pretty large monorepo and require quite granular rules. At the moment the highest number of patterns is 26 for one required reviewer but that may increase in the future.

Thanks for the amazing work on this feature.

[avivka]

Joining the good feedback and the suggestion to increase the limit. I'm actively working on an ADO -> GitHub Migration with few organizations that are reaching this limit quite easily @patrick-knight

[douglasg14b]

Subteams don't show up on the list of teams, which largely defeats the utility for us.

If we have a team my-domain and that then has subteams for each team within that domain, none of those show up, even though we already use those in our CODEOWNERS file without issue.

[gabrieltaylor]

@douglasg14b I found this too. You can work around this at the moment by granting the sub-team explicit access to the repo rather than the team inheriting access from their parent.

[patrick-knight]

We're looking into this one right now.

[patrick-knight]

We have a fix for this landed and expect to roll it out in early January 2026.

[DarylCantrell]

The fix is now 100% enabled on github.com.

[laughedelic]

Please, allow adding "Repository admin" role as a required reviewer. Same way as it's possible to add a bypass for this (and some other) "dynamic" roles:

This allows adding a ruleset at the org level that has a different required review team for each repository, depending on the admin of that repository. No need to manually create a ruleset for each repo, thus it is much more scalable

[patrick-knight]

Thanks for the feedback @laughedelic. At the moment we need to ensure compatibility with our PR logic, so we've mirrored the actor constraints (e.g., roles) currently found in CODEOWNERS.

[dtschiffman]

Hey @patrick-knight Love the addition of this new feature. This is something we have wanted since switching to GitHub. Just discovered it yesterday. We have a custom action running on every PR currently that solves the problem this addresses, Unfortunately we have one use case that is not supported.

Please add the ability to not request a review from the required team. Sounds strange but it would be a very useful setting.

With AI, now non-engineers could write code and open Pull Requests. But we would want to require a Engineer reviews every PR before they can be merged. We have a github team that contains all the engineers at the company, but if you use this setting it will ping everyone in the company, which is way too noisy. There is other uses for this too we would want to use it for, but this is one I imagine we might share with other companies.

( Side note: I also noticed that a team with round robin autoassignment and the Team review request: When assigning team members, remove the review request for the team. setting enabled doesn't seem to remove the required team. There is some inconsistencies with the github team settings and this new feature that you will probably want to fully explore. )

I just want a toggle that lets me not request a review from a team, but still require it. That is the biggest blocker for us being able to use this currently. Thanks again for implementing this feature.

[stevehipwell]

@dtschiffman have you considered using an additional team with notifications disabled for this?

[patrick-knight]

@dtschiffman Thanks for the note. I'll pass this over to our PR team. We’re aiming for a more generic implementation with this rule to avoid over-complicating it, especially since the existing review system already handles reviewer notifications.

[dtschiffman]

I did attempt using an additional team with notifications disabled but that is one of the inconsistencies I noticed. It still notified people despite the notifications being disabled. Which was strange. It is a little disappointing to hear that our use case is too complex for this rule. It would have been nice to be able to use it. But in its current implementation it is not useable, since it doesn't seem to respect the notifications settings set in the team settings.

[gabrieltaylor]

@patrick-knight If possible it would be great if there could be a different UI treatment that informs users when review is required by a particular team. For context in our current setup teams own many files via the CODEOWNERS file and are required reviewers on a subset of those files via Rulesets. When an owned file is modified the owner is added as a reviewer alongside the "shield with keyhole" icon. There is no indication in the assigned reviewers section if their review is blocking or not based on the file matching the Rulesets. There is an indicator in the Merging is blocked section but it would be nice if there was an at a glance UI indicator in the assigned reviewers.

Example

Team Backend is the code owner but the PR is NOT blocked waiting on their approval.

Team Backend is the code owner AND the PR is blocked waiting on their approval.

[patrick-knight]

Let me run this my some folks and see what's possible here. We didn't change this UI because the view was a required review from CODEOWNERs or Rulesets is functionally equivalent in the results and will be displayed in the merged box, but I hear you that surfacing the info earlier front runs having to wait for the merge status.

[lavoiesl]

First off: Thank you for doing this 🙏🏼

A great feature of CODEOWNERS is that it warns you that you're about to request a review from a team, but does NOT do so until you mark the PR as ready to review.

To build on what @gabrieltaylor said, I'd suggest to augment the UI as this:

[patrick-knight]

replied above: https://github.com/orgs/community/discussions/178776#discussioncomment-15619815

[lavoiesl]

I'm currently implementing this for my team and I find that the ruleset being in the settings is not very user friendly, especially in terms of discoverability. Most environments where this feature is useful do not grant users access to the settings.

Therefore, I'm currently working on a code-as-configuration design like this:

# .slices/ci.yml:
description: Continuous Integration Workflows
reviewers:
  admins: ~
file_patterns:
  - '.github/workflows/ci-*.yml'

# .slices/javascript.yml:
description: JavaScript Files
reviewers:
  javascript-core-team:
    minimum_approvals: 1
  frontend-team: ~
review_bypass:
  admins: pull_request
file_patterns:
  - '**/*.js'
  - '**/*.ts'

Upon a push to main, it triggers a workflow that compiles 1 ruleset per slice and upserts it via the API.

Additionally, it automatically applies slice:<name> and team:<slug> labels to PRs based on changed files.

Why Slices?

• Components first: The semantics is first on the component, not the team.
• Co-ownerships: Components can have multiple stewards.
• Long-lived: Teams change over time, but components are more stable.

This is probably overkill for the feature you're building, but I thought I'd share.

The code-as-configuration is a big winner IMO.

[jackmtpt]

We built something pretty much the same as this for Azure DevOps, using the terraform provider. Have you considered writing this using terraform for github?

[lavoiesl]

I considered it, but I much prefer having the configuration in the repo itself because it allows the users/maintainers of that repo to self-govern, as opposed to having a separate repo that one needs to contribute to.

[patrick-knight]

Glad to see you found ways to extend this. One of the benefits of rulesets is how they can also apply from the enterprise and org level, as well as target branches things that would be complex to introduce in CODEOWNERs, so we have to make some trade offs. Also worth noting there is a fine grain permission for editing rulesets if you wanted to extend who has access directly in setting.

[lavoiesl]

Also worth noting there is a fine grain permission for editing rulesets if you wanted to extend who has access directly in setting.

I couldn't find one at https://github.com/settings/apps/new and https://docs.github.com/en/rest/repos/rules?apiVersion=2022-11-28#update-a-repository-ruleset specifically says:

The fine-grained token must have the following permission set:
"Administration" repository permissions (write)

[lavoiesl]

FWIW, here's the implementation I made: https://github.com/coveooss/areas

[debben]

Is there anything on the roadmap for implementing something similar for statuses? I'm in the processes of moving from Azure Repos to Github. Branch protection rules in Azure Repos offer path filtering both for assignment of required reviewers but also for requiring specific status for matching paths.

[patrick-knight]

Not at the moment, but it's been a topic we discuss internally from time to time.

[lavoiesl]

Suggestion:

File patterns are a very powerful way to control rulesets.

I would suggest moving the concerns from the "Require a pull request before merging > Require review from specific teams" section and to the root of the ruleset.

Reasons:

1. Adding a ruleset that says that every *.rb file must be reviewed by a team forces the enabling of the "Require a pull request before merging" rule, even if the changes don't match any pattern.
2. Many other features could benefit from being restricted to a file pattern (mandatory statuses, require deployment to succeed, require code scanning, etc.)

[patrick-knight]

I mentioned above we've discussed this before and would likely use the bypass list behavior to exclude paths from enforcement, but high speculative at the moment as we don't have planned investments at the moment.

[jvdl]

I would love this feature if it wouldn't automatically add the team as a reviewer – especially when I've already added someone from that team as a reviewer directly.

What we're after is basically a "Review in this repo required from this team" but we don't want the whole team to notified or have their review inbox filled up with team review requests.

Our workflow is along these lines - we have multiple teams in our product, and each team is has 1 or more repositories they work with. Repository/Code ownership is at the team level - so let's say Team A owns Repo A and Team B owns Repo B.

Sometimes member of Team A works in Repo B, and so someone from Team B should review that pull request, we just add a specific team member or two from that team to have the code reviewed.

While this feature gets us part of the way there - as in we're able to enforce a review of the code in Repo B by a member of Team B - the feature will add the team as a reviewer to the PR, even though a member of Team B was already explicitly added to the PR.

• IMO this would work nicer if the team was not added as a reviewer, but only enforced as a rule. Either as an option to "never automatically assign teams" or "only assign teams when no matching reviewers are added" or something along those lines.
• Bonus points if the reviewer list could also suggest required reviewers. e.g. if I open the "Reviewers" selection popup it could prepopulate the suggested section at the top with required reviewers. For instance "John Smith | member of ".

At the moment it feels like some parts of this feature is "CODEOWNERS but configured from a Ruleset", the CODEOWNERS feature has some of the same problems, so I'm guessing this probably uses a lot of the same stuff under the hood, so solving/improving this may benefit both of these features :-)

[daveallie]

+1 - having the team assigned to the PR is a huge drawback as it pollutes individual's "Required Reviews" queue.

Even when the team has "Auto assignment" and "Team review request" enabled, the team is left on the PR which feels confusing and unnecessary, especially because it's called out that the team is required to review the PR before merging at the bottom of the PR.

[patrick-knight]

Today there is a requirement in pull request reviews for teams to have direct access so CODEOWNERS and this rule are under the same constraints.

[jackmtpt]

Is this meant to be available at the enterprise level? For my enterprise branch policy I have these options:

only when creating a new org-level policy do I see the setting for specific team review:

[patrick-knight]

It will not be available as enterprise teams are not supported in pull requests reviews at the moment.

[brenank]

@patrick-knight This is a great start!
I’d like to request more granular control over required reviews based on both path and team membership.

Specifically, for a given path, I want to be able to skip required reviews when the author is a member of a specific team, while still requiring reviews for everyone else.

I see this idea touched on above, but not as its own distinct request:

Concrete example (based on @dtschiffman's comment above):
If a user is a member of @myorg/admin-team, they should be able to modify **/.tf files with 0 required reviewers.
If a user is not on that team (e.g. a member of @myorg/project-team), changes to **/.tf files should require approval.

Today, “require reviews from a specific team” is effectively one-dimensional: it can enforce who must review, but it can’t express who is exempt from review requirements. This request is about adding that missing dimension.

[lavoiesl]

FWIW, you can get very close to that with the current implementation, albeit at significant configuration cost.

You can configure rulesets to require reviews, but allow certain people or teams to bypass the requirements.

Things can always be made more powerful or complex, but at the cost of simplicity and ease of use.

I think the current implementation strikes a good balance. On top of it, I like the bypass UI that forces the user to acknowledge that they are bypassing the rules.

[brenank]

True, yeah unfortunately, that would allow bypassing review (as well as status checks etc) across the entire repo.

It would be nice if there was an option that is specific to reviews. Maybe a checkbox on the require review from specific team to "skip review if pull request was created by someone on this team" or similar.

[lavoiesl]

You can split the rulesets and have multiple targeting the same branch.

Create a ruleset just for the reviews that can be bypassed and the other rulesets will still be enforced

[brenank]

Ah nice, I'll try that out thanks!

[r-leyshon]

Thanks for this great feature. I have a question about this rule in combination with "Dismiss stale pull request approvals when new commits are pushed". Is it possible to only require an additional review if the target files have been updated?

Example:

• Infra team approves update to main.tf
• Branch updated with frontend adjustments. Infra team approval required once more.

Is it possible to retain the infra team approval unless further main.tf updates are pushed.

[patrick-knight]

We've investigated the idea of "sticky reviews" but have not prioritized it so far.

[patrick-knight]

Quick update. We're going to mark this as GA next week to note it's a stable feature.

Doesn't mean you shouldn't keep sending feedback our way. Y'all helped up find the sub-team issues and helped champion the ! path exclusions.

[larros]

Is there a plan to have this taken into accout in the PullRequestReviewDecision? All other approval related rules are showing as REVIEW_REQUIRED if they are not fulfilled, but this is not the case for the "Require review from specific team" rule.