ci/review-policy: allow to use from other repos

Make the review-policy workflow reusable (via workflow_call), so other
opencontainers repositories with the same merge rules (such as
opencontainers/cgroups, see opencontainers/cgroups#91) can call it
instead of carrying a copy.

The calling repository gets the same logic, which is fine, since:
 - CHANGELOG.md and vendor/ exceptions are no-ops where there's no
   such file/directory;
 - the merge_group trigger is the caller's, and it's harmless when unused.

The only difference was CODEOWNERS, which cgroups treats as a governance
file. Add it here, too, as it does define who reviews what.

Document how to use it from another repository.

Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>

.github/workflows/review-policy.yml

@@ -22,11 +22,32 @@
 # (see isGovernanceFile below), and changes to it must be reviewed carefully.
 # Also, keep it read-only: do NOT add write permissions, secrets, or
 # actions/checkout.
+#
+# Other repositories can use this workflow via workflow_call, by having a
+# .github/workflows/review-policy.yml file like this:
+#
+#   name: review-policy
+#   on:
+#     pull_request_review:
+#       types: [submitted, edited, dismissed]
+#   permissions: {}
+#   jobs:
+#     review-policy:
+#       permissions:
+#         contents: read
+#         pull-requests: read
+#       uses: opencontainers/runc/.github/workflows/review-policy.yml@<sha>
+#
+# Always pin it to a commit SHA, so the rules can only be changed by a
+# governance change in the calling repository. The rules are the same as
+# here; the calling repository must document them in its MAINTAINERS_GUIDE.md.
+# Note the required status check name is then "review-policy / review-policy".
 name: review-policy
 on:
   pull_request_review:
     types: [submitted, edited, dismissed]
   merge_group:
+  workflow_call:
 
 permissions: {}
 
@@ -85,7 +106,7 @@ jobs:
 
             // Files defining the project rules, or enforcing them.
             function isGovernanceFile(f) {
-              return f === 'MAINTAINERS' ||
+              return f === 'MAINTAINERS' || f === 'CODEOWNERS' ||
                 (f.endsWith('.md') && !f.includes('/') &&
                   f !== 'README.md' && f !== 'CHANGELOG.md') ||
                 f.startsWith('.github/workflows/review-policy');

MAINTAINERS_GUIDE.md

@@ -77,9 +77,10 @@ A pull request can be merged once it has:
   other maintainers a chance to review and object.
 
 A pull request is a governance change if it changes the rules of the project,
-or how they are enforced. That is, it changes `MAINTAINERS`, a top-level `*.md`
-file other than `README.md` and `CHANGELOG.md` (such as this document), or the
-`review-policy` workflow. A governance change always requires two LGTMs.
+or how they are enforced. That is, it changes `MAINTAINERS`, `CODEOWNERS`,
+a top-level `*.md` file other than `README.md` and `CHANGELOG.md` (such as this
+document), or the `review-policy` workflow. A governance change always requires
+two LGTMs.
 
 A pull request is a routine change if it is not a governance change, and it is
 either: