Your org requires branch protection on main everywhere, but a critical tool has just one maintainer who finds required review genuinely slows down urgent fixes. How do you balance this?

Required status checks (CI passing) should apply universally regardless of team size, since that's automated and adds no human-availability bottleneck — required human review is where the actual tension lies, and the practical resolution is usually a scoped exception (documented, not silent) rather than either blanket enforcement that ignores real friction or blanket exemption that undermines the org-wide standard. Options include allowing the maintainer to self-approve for genuinely low-risk changes with a fast-track process, pairing them with an on-call reviewer from an adjacent team for when speed matters, or accepting a documented, time-bound exception for this specific repository given its actual risk profile.

The tension here is real, not imagined — required review genuinely does add friction, and for a true single-maintainer situation, "wait for another reviewer" can mean waiting for someone with essentially no context on the tool, which doesn't produce the intended safety benefit of review (someone catching a real issue) so much as it produces pure delay.

Distinguish required status checks (automated) from required human review (has a real availability cost): required CI checks passing don't depend on another human's availability at all, so there's no real reason to exempt any repository from this baseline regardless of team size — the actual friction is specifically about human review requirements, which is where a nuanced approach is warranted.

A documented, explicit exception is better than either extreme: silently allowing this one repository to have weaker protection (nobody officially deciding this, just informally not enforcing the standard) creates an invisible gap that undermines the organization's ability to reason about its actual security posture — an explicit, documented exception (approved by whoever owns the org-wide standard, with a stated reason and ideally a review date) preserves visibility into where and why the standard doesn't apply, while still accommodating the genuine constraint.

Consider whether a genuinely fast-tracked review process solves the problem better than an outright exemption: pairing the solo maintainer with a designated backup reviewer from an adjacent team (even without deep tool-specific context, a second set of eyes catches some categories of mistakes — an obvious typo, a clearly wrong config value) can provide real review value without requiring the maintainer to wait for someone with full context, addressing the speed concern without fully abandoning the review requirement.

Distinguish low-risk from high-risk changes within the same repository: if the tool has some changes that are genuinely low-risk (documentation, minor config tweaks) and others that are higher-risk (core logic changes, security-relevant code), a tiered approach — self-approval allowed for the low-risk category, required review for the higher-risk category — can be more proportionate than a uniform policy either way.

The org-wide standard's value comes from consistency and visibility, not necessarily zero exceptions: a small number of well-documented, deliberately-approved exceptions for genuine edge cases doesn't undermine an org-wide standard the way silent, ad hoc non-compliance does — the goal is that anyone auditing the organization's security posture can see exactly where the standard applies, where it doesn't, and why, rather than assuming uniform enforcement that doesn't actually reflect reality.

• Required status checks (automated CI) should apply universally regardless of team size — the real tension is specifically around required human review, which has a genuine availability cost for a true solo maintainer.
• A documented, explicitly-approved exception (with a stated reason, ideally time-bound) is better than either uniform, friction-heavy enforcement or silent, invisible non-compliance.
• A designated backup reviewer from an adjacent team can provide real review value without requiring the wait for someone with full tool-specific context.
• Tiering the requirement by actual change risk (self-approval for low-risk changes, required review for higher-risk ones) can be more proportionate than a uniform policy in either direction.

• GitHub Docs: About protected branches