Identify the files whose changes require human ownership
A small museum maintains a web form for volunteer permissions and an AI-assisted tool that summarizes submissions. The consent copy, retention configuration, and server-side export code are stored in one GitHub repository. A routine pull request that changes a button color is not equivalent to a pull request that changes what volunteers authorize. CODEOWNERS offers a way to request reviews from designated people when specific files are touched, provided the repository rules are configured correctly.
Begin with a file inventory: `/consent/`, `/privacy/`, the API handler that stores form data, and the `CODEOWNERS` definition itself. Assign each protected path to a real reviewer or team with suitable repository write access. The scenario is hypothetical and does not describe a deployed consent system. Use it to decide what must not be merged without legal, privacy, and technical review.
Understand what CODEOWNERS does and does not enforce
GitHub checks the CODEOWNERS file in the pull request’s base branch when determining requested reviewers. A valid entry maps a path pattern to one or more owners. GitHub documents search locations including `.github/`, the repository root, and `docs/`, and pattern precedence matters: the last matching pattern takes priority. An invalid owner or a team without write access can leave changes without the intended ownership assignment.
Reviewer requests by themselves are not a merge gate. To require code owner approval before merging, repository administrators must enable an applicable branch protection rule or ruleset with the required-review setting. An ordinary draft pull request does not automatically request code-owner reviews until it is ready for review. Treat the protection rule, file patterns, and effective permissions as three separate controls that must be verified together.
Write path patterns for the sensitive surfaces
A possible controlled configuration gives the privacy team ownership of `/consent/` and `/privacy/`, assigns the backend data-export handler to maintainers, and explicitly protects `/.github/CODEOWNERS` itself. GitHub advises protecting the ownership file to prevent a contributor from weakening the very review requirement that guards other files. Keep patterns concise and read them in order, because a broad later rule can unintentionally replace a more specific owner.
Validate case sensitivity and the presence of the real files. GitHub’s CODEOWNERS syntax resembles gitignore but differs in important respects; certain negation and character-range constructs are not supported. The file also has a documented 3 MB limit. Do not copy elaborate ignore-file patterns assuming they behave identically. A repository test should include changed paths that match, paths that should not match, and paths newly added by a feature.
Make required reviews effective on the protected branch
Configure the protected main branch so changes reach it through pull requests with the required reviewer controls. Check whether administrator bypasses, allowed actors, dismissing old approvals, and stale branch states can weaken the desired workflow. For a sensitive consent handler, a code owner approval should be a minimum requirement, not a complete security assessment or a claim that a policy is legally sufficient.
A useful dry run changes a harmless string in a fixture under `/consent/`. Confirm that the expected reviewer is requested when the pull request becomes ready, and that merging is blocked until an eligible owner approves. Then exercise a change in an unrelated style file and verify that it follows the intended general review policy. Finally, test a modification to CODEOWNERS itself to ensure ownership does not disappear silently.
Protect against changed wording that preserves valid syntax
A pull request can pass unit tests while subtly weakening consent language. For example, changing “We may retain the recording for 30 days” to “We may retain the recording” could remove a material limit without breaking code. The designated reviewer must compare the proposed wording with the approved policy and the data flow. A green CI status or another reviewer’s approval cannot establish that the new consent remains informed.
Maintain a short checklist for semantic risk: retention term, optional versus mandatory consent, data recipients, right to withdraw, and accessible explanation. Review any hidden form fields or defaults that may collect more data than the visible sentence promises. Ask the person responsible for the actual policy to sign off on high-risk changes; CODEOWNERS only routes responsibility to reviewers and does not grant automatic legal authority.
Review edge cases: teams, branches, and draft changes
GitHub owner teams must be appropriately configured and have write access to the repository. Teams renamed or removed after a file was written can invalidate ownership unexpectedly. Reviewers can also be missing because the CODEOWNERS file on the base branch is stale or a pattern never matched. Do not use an opened pull request’s banner as your only verification; inspect effective reviewers and whether merge is actually blocked.
Test branches that receive long-running maintenance fixes, not just `main`. If a security backport targets another protected branch, its base-branch CODEOWNERS file may be different. Also test draft-to-ready transitions. Document escalation when the named owner is unavailable; disabling review protections for speed can expose the organization to a much larger consent and data-handling failure.
Keep evidence of review without copying private submissions
For each change, keep the pull request, path changes, approval decision, linked policy revision, and release reference. There is no reason to attach volunteer submissions, full access tokens, or donor contact records to a review screenshot. Use synthetic fixtures and redacted logs for testing. If an AI coding assistant proposes a change, it remains an untrusted contribution requiring the same review and testing steps as any human-authored patch.
Do not conflate responsibility for a file with permission to read private submissions at runtime. CODEOWNERS governs repository review routing, not database row access, production secrets, or WordPress publishing privileges. Keep those permissions in separate systems. Audit CODEOWNERS and branch protection during ownership changes so a configuration that once worked does not quietly drift.
Release only after content, behavior, and governance agree
Before merging, verify the real owner approved, the automated tests passed, the form preview matches the approved language, and downstream data processing still follows the retention policy. Record the authorization for publishing a new consent version independently from the GitHub merge. If a significant discrepancy is found, stop the release and restore the prior approved wording or implementation until it is resolved.
A useful pilot is a set of synthetic pull requests representing a wording edit, a backend export change, a harmless CSS change, and an attempted CODEOWNERS alteration. Inspect which reviewer is requested and whether merge gates behave as designed. Document expected behavior, do not claim tests were run on an actual museum repository, and revisit current GitHub documentation whenever ruleset or plan capabilities change.
How We Research
For this November 2026 guide, we reviewed named primary documentation: GitHub: About code owners; GitHub: About protected branches. We checked documented settings, limits, and failure conditions against a fictional institutional use case. We did not run live vendor API tests, process actual private records, verify real-world speech or translations, measure latency, or collect permissions. All images are original conceptual instructional drawings rather than screenshots or observations. Claims about source revisions, speaker wording, ownership, and access must be checked against the authoritative records by qualified staff. Vendor capabilities, eligible plans, regions and logging behavior can change; check current documentation and institutional policy before deploying any workflow.
Frequently Asked Questions
No. Code-owner review must be required using applicable branch protection or rulesets.
GitHub uses the CODEOWNERS file in the base branch targeted by the pull request.
Not automatically. Requests are made when a draft is marked ready for review.
GitHub documents that one approval from the listed owners can satisfy the code-owner requirement; other review rules may add requirements.
Yes. Assign ownership to the CODEOWNERS file or its containing directory so ownership rules cannot be weakened casually.