Required reviews provide little protection if too many people or apps can dismiss them. GitHub rulesets now let organizations name the actors allowed to clear a review instead of relying on broad repository administration rights.

Quick answer

Limit dismissal rights to a small maintained team, preserve a documented emergency path, require reasons, and audit every use. Repository owners should not automatically gain routine permission to erase another reviewer’s decision.

review_dismissal_policy:
  allowed_teams:
    - code-owners-admins
  emergency_team:
    - incident-commanders
  require_audit_review: true

what changed

Repository rulesets can now restrict review dismissal to selected users, teams, or apps. This adds a focused control around approval state without requiring teams to redesign the entire pull-request rule.

This is a current platform change, so confirm availability for your plan, organization, and installed client before changing a production workflow. Preview features can also change faster than generally available controls.

who should use it

The control is especially valuable for protected production repositories, regulated code, and projects where review decisions come from security or domain owners. It also reduces accidental dismissal during routine maintenance.

The practical question is whether the feature removes a real bottleneck or security gap in your workflow. A new control is not valuable merely because it exists; it needs an owner, a narrow purpose, and an observable result.

a safe implementation

  1. List legitimate dismissal scenarios.
  2. Assign the smallest stable team.
  3. Test interaction with administrators and bots.
  4. Review audit events on a fixed schedule.

Make the first rollout small enough to reverse. Record the previous behavior, the setting or command that changed it, and the person responsible for deciding whether the experiment expands.

the mistake to avoid

Do not remove every emergency path. During an unavailable reviewer or compromised account incident, the team needs a controlled procedure that restores progress without silently bypassing policy.

Convenience features still operate inside your existing trust model. Repository permissions, protected environments, review rules, test accounts, and audit logs remain important even when the new workflow removes manual steps.

how to verify it

Use a test repository to request changes, attempt dismissal as an ordinary maintainer, then repeat as an approved actor. Confirm the event appears in audit records with the expected identity.

Keep the verification evidence in the pull request or rollout ticket. That gives reviewers something concrete to evaluate and gives the next person a known baseline when the platform changes again.

rollout checklist

  • Confirm the feature and client version are available.
  • Test with non-production data and minimum permissions.
  • Capture expected success and failure behavior.
  • Document rollback and ownership.
  • Recheck the official announcement before a wide rollout.

official reference

The announcement is the source of truth for availability and product behavior. This article focuses on the implementation decisions teams should make around it.