From 23fdbacd11dc3a572045b46f4fe896877bc7d391 Mon Sep 17 00:00:00 2001 From: Herbert Damker <52109189+hdamker@users.noreply.github.com> Date: Thu, 6 Aug 2026 14:26:54 +0200 Subject: [PATCH 1/2] docs(validation): note fork-PR approval gate in codeowner guidance MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit For a contributor who trips the org's fork-PR approval policy, the CAMARA Validation check doesn't just fail — it's absent from the checks list until a maintainer approves the pending workflow run. SimSwap#276 is a concrete case of this being missed. --- documentation/validation/pull-requests.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/documentation/validation/pull-requests.md b/documentation/validation/pull-requests.md index d6961bd1..c69afc57 100644 --- a/documentation/validation/pull-requests.md +++ b/documentation/validation/pull-requests.md @@ -30,7 +30,8 @@ When the short message is not enough to act, look up the rule code in the [Valid ## Codeowner guidance -Codeowners should not intentionally merge errors to `main` unless the repository has explicitly accepted the resulting release-process risk. The release process at `/create-snapshot` will block until the errors are gone. Warnings and hints are not blocking, but a codeowner reviewing for merge should at least scan the workflow summary and confirm the warnings make sense in context — many of them indicate something that will block a later release type. +- Do not intentionally merge errors to `main` unless the repository has explicitly accepted the resulting release-process risk. The release process at `/create-snapshot` will block until the errors are gone. Warnings and hints are not blocking, but scan the workflow summary before merge and confirm the warnings make sense in context — many of them indicate something that will block a later release type. +- Some pull requests need a maintainer to approve the workflow run before it can start at all. GitHub does this for pull requests it doesn't yet trust to run automatically — most commonly, someone's first pull request to the repository. Until a maintainer approves the run, it hasn't started, so the **CAMARA Validation** check is missing from the checks list entirely, not passing or failing. If a pull request has no CAMARA Validation check yet, open its **Conversation** tab and look near the merge box for a banner asking to approve the pending workflow run, rather than assuming there was nothing to check. For what each severity obligates your team to do, and why the same rule can report differently as your API's status advances, see [What a validation result obligates your team to do](severity-obligations.md). From bd444bc4316a4d0bcf570ae3b2e4d225def3a612 Mon Sep 17 00:00:00 2001 From: Herbert Damker Date: Thu, 6 Aug 2026 18:29:57 +0200 Subject: [PATCH 2/2] Update documentation/validation/pull-requests.md Co-authored-by: Kevin Smith --- documentation/validation/pull-requests.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/validation/pull-requests.md b/documentation/validation/pull-requests.md index c69afc57..e64a81c9 100644 --- a/documentation/validation/pull-requests.md +++ b/documentation/validation/pull-requests.md @@ -31,7 +31,7 @@ When the short message is not enough to act, look up the rule code in the [Valid ## Codeowner guidance - Do not intentionally merge errors to `main` unless the repository has explicitly accepted the resulting release-process risk. The release process at `/create-snapshot` will block until the errors are gone. Warnings and hints are not blocking, but scan the workflow summary before merge and confirm the warnings make sense in context — many of them indicate something that will block a later release type. -- Some pull requests need a maintainer to approve the workflow run before it can start at all. GitHub does this for pull requests it doesn't yet trust to run automatically — most commonly, someone's first pull request to the repository. Until a maintainer approves the run, it hasn't started, so the **CAMARA Validation** check is missing from the checks list entirely, not passing or failing. If a pull request has no CAMARA Validation check yet, open its **Conversation** tab and look near the merge box for a banner asking to approve the pending workflow run, rather than assuming there was nothing to check. +- Some pull requests need a maintainer to approve the workflow run before it can start at all. GitHub does this for pull requests it doesn't yet trust to run automatically — most commonly, someone's first pull request to the repository. Until a maintainer approves the run, it will not start, so the **CAMARA Validation** check is missing from the checks list entirely, not passing or failing. If a pull request has no CAMARA Validation check yet, open its **Conversation** tab and look near the merge box for a banner asking to approve the pending workflow run, rather than assuming there was nothing to check. For what each severity obligates your team to do, and why the same rule can report differently as your API's status advances, see [What a validation result obligates your team to do](severity-obligations.md).