Install the contribution governance for the OWASP re-launch

[rocklambros]

Operationalizes the contribution governance the core team agreed on September 8, filtered through the Strategic Adoption Plan v3 committed outcome.

Design: design/2026-09-09-contribution-governance-design.md (v1.1)
Plan: design/plans/2026-09-09-contribution-governance.md

What this installs

Current Priority Scope. CONTRIBUTING.md gains one section that states what the project is driving at for the next ninety days, what is deferred to v0.2.0, and what is out of scope by design. It is stated once. Every other surface links to it rather than restating it, and the landing page now renders it straight out of CONTRIBUTING.md so the two cannot drift.

Branching. main publishes the site and all 44 schema $id URIs on merge, so specification and code land on integration and publish on a deliberate promotion. A guard (tools/base_branch_guard.py, 16 tests) enforces a positive path allowlist and fails closed on anything nobody anticipated. The promotion exemption checks the head repository, not just the ref, so a fork branch named integration cannot walk a schema change onto the publishing branch.

Intake. Blank issues are off. Six forms route by type, and no form can stamp a scope:, priority:, workstream:, or status:accepted label. That prohibition is the whole structural guarantee behind maintainer-only triage. The sixth form asks for nothing but a description, because the strongest outside contribution this project has received would have fit none of the other five.

The gate. A change to behavior, normative text, or code references an issue carrying status:accepted. An editorial correction does not, wherever it lands. A pull request whose issue is not accepted yet is neither closed nor reviewed. It waits, and a bot says why.

Automation. Four workflows: the base-branch guard, an integration sync, a weekly promotion pull request, and the intake comment. Plus a reminder that opens an issue when the priority scope passes its review date.

Phase 2 executor. tools/apply_governance.py performs the live migration steps idempotently, --dry-run by default. It is structurally incapable of merging, closing, or retargeting a pull request, and a test asserts no code path can emit those commands.

Authorship policy change

The rule that a maintainer strips a Co-Authored-By trailer naming a model is removed. The project now mandates neither direction. The human Signed-off-by stays required, because only a person can make the DCO certification. A standard about agent provenance should not erase the provenance of its own commits.

Reviewer notes

• Nothing on the published site changes except the landing page's Contribute section. I built the full pipeline from main and from this branch and diffed: the only files that differ are index.html and acs.css. All 44 schemas are byte identical.
• 253 tests pass. mkdocs build --strict passes.
• This targets integration rather than main because it touches .github/, tools/, and tests/, which is exactly what the guard it installs requires.

Still to do after this merges

Retarget #63, #24, #60, and #22 to integration. Merge #21, #20, and #22 when the team is ready. Then run the executor for rulesets, default branch, required check, and the seeded issues. The order that matters is in the plan.

[rocklambros]

@afogel @bar-capsule tagging you both ahead of Thursday. Two areas where your judgment matters more than mine:

Ariel — the branching model and the guard. main publishes the schema URIs on merge, so specification and code go to integration and publish on a promotion. The allowlist of paths that may still target main is in tools/base_branch_guard.py and mirrored in CONTRIBUTING.md. If that list is wrong in either direction, say so. Also the seeded onramp in tools/apply_governance.py: those nine issues are the answer to "what code contribution do we actually need", drawn from what you said on the call about ports, batching, and OpenTelemetry collection. They go out under the project's name, so they should read the way you would have written them.

Bar — the issue forms in .github/ISSUE_TEMPLATE/. The specification proposal form asks a filer to make the case from SPEC_REVIEW_PRINCIPLES.md principle 3, that something goes on the wire only if it is lost otherwise, and to name which of the six constituencies it affects. If that framing sends people down the wrong path, it is worth changing now rather than after a hundred of them use it.

Two deliberate choices worth flagging, either of which I will reverse if you disagree:

1. The acceptance gate keys on what a change does, not on which branch it targets. An editorial correction needs no issue anywhere. Anything that changes behavior or normative text references an issue a maintainer has marked status:accepted. A pull request whose issue is not accepted yet is neither closed nor reviewed, it waits and a bot explains why.
2. priority:P0 is reserved for the four links in the serial chain and nothing else, so none of the seeded issues carries it. Slim ACS-Core: relax MODIFY, system/ping, and wrapped MCP to SHOULD #21 and Add adapters/ with Claude Code, Cursor, and NAT reference implementations #22 are the real P0s and should get the label during triage.

Nothing on the published site changes except the landing page's Contribute section, which now renders the priority scope directly out of CONTRIBUTING.md so the two cannot drift.

[bar-capsule]

I think this runs the pull request's own copy of the guard. On a pull_request event the checkout is the PR merge ref, so tools/base_branch_guard.py — and this workflow file itself — come from the change being judged. A PR that targets main and edits the guard's allowlist in the same diff gets a green required check from its own edited gate; CODEOWNERS review on /tools/ and /.github/ is then the only thing standing, and a green check is exactly what softens that review.

The trigger and permissions can stay as they are — only the script's provenance needs to change. BASE_SHA is already in the environment and fetch-depth: 0 already makes it reachable:

  - name: Enforce the documentation lane
    env:
      BASE_REF: ${{ github.event.pull_request.base.ref }}
      HEAD_REF: ${{ github.event.pull_request.head.ref }}
      HEAD_REPO: ${{ github.event.pull_request.head.repo.full_name }}
      BASE_REPO: ${{ github.repository }}
      BASE_SHA: ${{ github.event.pull_request.base.sha }}
    run: |
      set -euo pipefail
      # Run the BASE branch's guard, not the PR's: a diff that edits the
      # guard must not be judged by its own edit.
      git show "${BASE_SHA}:tools/base_branch_guard.py" > /tmp/base_branch_guard.py
      python3 /tmp/base_branch_guard.py changed.txt

The workflow file itself staying PR-controlled is a residue this can't close (that's inherent to pull_request triggers); the base-sourced script at least makes the bypass require deleting the enforcement step outright, which is louder in a diff than a one-line allowlist edit.