Maintainers

This file is the canonical record of who has merge authority on github.com/openwop/openwop and what's expected of them. The maintainer set drives the decision rules in GOVERNANCE.md and the RFC process in RFCS/.

Recruitment of additional maintainers is out of band: this file documents the criteria and the process. It does not commit to a hiring schedule. The vendor-neutral-org migration tripwire in ROADMAP.md activates when this file lists at least one maintainer not affiliated with the original steward.

Current maintainers

The lead maintainer is the tiebreaker for unresolved disagreement (per GOVERNANCE.md §"Decision making"). The lead-maintainer role is transitional and is replaced by a steering-committee vote once the path-to-working-group conditions in GOVERNANCE.md are met.

Maintainer expectations

A maintainer is expected to:

1. Respond. Acknowledge issues and pull requests in their area within five business days. Acknowledgment may be a substantive reply or a "I'll get to this by ~date" — silence is the failure mode this rule exists to prevent. 2. Gate quality. Merge only changes that pass the CI gates listed in CONTRIBUTING.md §"The CI gate." A failing CI run is never a "fix-forward" rationale on main. 3. Follow the spec change process. Per GOVERNANCE.md §"Spec change process" — editorial / non-normative-addition / normative-addition / breaking each have their own decision rule and comment window. RFCs follow RFCS/0001-rfc-process.md. 4. Disclose conflicts. Any commercial relationship, funding source, or employment that could bias a decision is disclosed in the PR or RFC thread. Recusal is the default for direct conflicts. 5. Honor compatibility. Apply COMPATIBILITY.md strictly. v1.x stays additive-only by default; safety/security breaks follow the §3 process; v2 is the parallel track for everything else. 6. Update governance docs in lockstep. Changes to maintainer status (additions, removals, role changes) update this file via PR. Changes to GOVERNANCE.md decision rules go through the RFC process. 7. Uphold registry policy. Maintainers acting as registry approvers apply the submission, trust-tier, and signing rules in RFCS/0043-registry-and-extension-policy.md §B (indexed at docs/governance/registry-policy.md) — including the registry-root-key rotation dual-control requirement (§B.4).

Promotion process

A contributor becomes a maintainer through these steps:

1. Sustained contribution. Six months of substantive review or PR activity on the openwop corpus. "Substantive" means non-trivial spec / schema / SDK / conformance contributions, not just typo fixes. 2. Nomination. An existing maintainer opens a PR adding the contributor to this file. The PR explains why the contributor meets the criteria. 3. Lazy-consensus window. Seven calendar days during which any existing maintainer may object. Substantive objections move the proposal to a discussion in the PR thread; unresolved objections are settled by lead-maintainer tiebreaker per GOVERNANCE.md. 4. Onboarding. The new maintainer is added to repository admin, CODEOWNERS for their declared area, the security advisory team (SECURITY.md), and announced in CHANGELOG.md under ### Governance.

A contributor may decline maintainer nomination at any time without explanation.

Stepping down

A maintainer may step down by opening a PR that:

• Moves their entry from "Current maintainers" to "Past maintainers" below.
• Lists their last active month.
• Optionally hands off ownership of any RFCs or open PRs in their queue.

Stepping down is acknowledged by lazy consensus (the PR merges with one approval). Past maintainers are not silently removed — the table preserves the history.

Removal for cause

A maintainer may be removed by lazy consensus of the remaining maintainers for:

• Sustained inactivity. No substantive activity for six months, with no advance notice.
• Code-of-conduct violation. Per CODE_OF_CONDUCT.md. Removal is by majority of remaining maintainers; the lead maintainer recuses if the violation involves them.
• Conflict-of-interest violation. Failure to disclose a conflict that materially affected a decision. Removal follows the code-of-conduct process.

A removed maintainer's entry moves to "Past maintainers" with a brief note on the removal reason. The note is factual; it doesn't repeat any private investigation detail.

Affiliation policy

Maintainers list their primary affiliation in the table. The affiliation field exists so:

• Cross-organization decision rules (per GOVERNANCE.md §"Decision making" — required for breaking changes once multiple orgs are represented) can be evaluated.
• External implementers can assess governance neutrality.
• The vendor-neutral-org migration tripwire in ROADMAP.md can be checked mechanically.

A maintainer who changes affiliation updates this file in the same PR. Multiple affiliations may be listed if they're material to recusal decisions.

Past maintainers

_None yet._

Recruitment log

The vendor-neutral-org migration tripwire in ROADMAP.md activates when this file lists ≥1 maintainer not affiliated with OpenWOP. Recruitment is out-of-band: this section tracks attempts (and their outcomes) so the project's recruitment posture is auditable, but it doesn't commit to a hiring schedule.

External host implementations

Recruitment targets per docs/recruitment/external-host.md (drafts ready 2026-05-11; freshness re-verified 2026-08-13 — content DID drift and was corrected: three quoted conformance pass rates came from a suite ~40 versions old and now point at dated, re-derivable measurements instead. Outreach still not sent — but as of 2026-08-13 it is sendable: external-host.md carries zero unfilled placeholders, the four scheduling slots that required a Calendly link the steward may not have are now plain "name two or three windows" asks, and every quoted figure points at a dated measurement. Sending is the remaining act and it is the tripwire for RFC 0035 and RFC 0038 both — neither is blocked on the world having declined, only on nobody having asked).

When a target replies positively + commits to a draft adapter PR within 30 days, move their row's status to in-progress. When their host appears on INTEROP-MATRIX.md, status → live.

External pack authors

Recruitment targets per docs/recruitment/external-pack-author.md (drafts ready 2026-05-11; freshness re-verified 2026-08-13 — no numeric drift found in this file; outreach still not sent). Initial Tier-1 shortlist below; the recruitment doc's criteria gate adding more.

When a target replies, fill in Outreach sent + First reply, advance Status through in-discussion → pack-drafted → published. When their pack lands on packs.openwop.dev, status → live.

Follow-up cadence: Day +5 / +12 / +28 nudges per docs/recruitment/follow-up-cadence.md. After Day +28 with no reply, the lead is cold — re-contact only on a real trigger (new release, new endorsement, new evidence) at Day +90.

Governance migration trigger

When the first non-steward maintainer is added to the "Current maintainers" table above:

1. Add the recruitment log row that produced them. 2. Open the vendor-neutral-org migration RFC per RFCS/0001-rfc-process.md (Phase 4 T4.1 in docs/PROTOCOL-GAP-CLOSURE-PLAN.md).

Bootstrap-phase RFC waivers

**⚠️ The grant below authorises less than has been done under it (audited 2026-08-20 — see

docs/WAIVER-AUDIT-2026-08-20.md).** It permits

additive RFCs, Draft → Active. At least five RFCs — 0147, 0148, 0149, 0150, 0156 — are

non-additive and were promoted to Accepted. RFC 0147 additionally forbids waiving

the comment window for RFCs touching identity, authorization, idempotency, replay or

certification (§A.6), and was itself waived while affecting four of them. Reconciling the

text with the practice is on the maintainer's desk; nothing has been reversed on this basis.

Completeness is now gated. scripts/check-waiver-ledger.mjs (step 6 of openwop:check)

fails if an RFC the tree shows as waived has no row here. The ledger drifted to 26 rows

against 41 derived before that gate existed.

Per CONTRIBUTING.md §"Bootstrap-phase notes," additive RFCs MAY be promoted Draft → Active by steward decision when the comment window would only serve as a delay against zero external reviewers. This section tracks every RFC that has used the waiver so future maintainers can audit the velocity of bootstrap-phase decisions. The waiver is retired automatically when the first non-steward maintainer joins.

When the count gets uncomfortable (e.g., > 5 waivers within a 30-day window, or > 15 total before the first non-steward maintainer joins), that's a signal to slow down and stage at least one RFC through a real 7-day window even without external reviewers — exercising the process is itself a credibility surface.

Tripwire status (2026-06-11): crossed. This ledger now records 26 waivers with no non-steward maintainer yet — past the > 15-total threshold above (and the 2026-05-25 – 2026-05-30 cluster alone exceeded the 5-in-30-days signal). Per the policy this is the signal to slow down: the slow-down response should be evaluated now, and at least one upcoming RFC should be staged through a real 7-day comment window even without external reviewers. The 2026-06-11 backfill itself is part of the response — the ledger had silently lagged at 5 rows while ≥ 19 RFCs carried "comment window waived" language; every discoverable waiver is now recorded. The tripwire is deliberately retained, not raised.

Waivers not annotated at the time (added 2026-08-20)

These twenty-one RFCs used the waiver but were never entered above. The rationale column is absent rather than reconstructed — nobody recorded why at the time, and a plausible after-the-fact reconstruction would be worse than an honest gap: it would read as a decision that was made. What is below is derived from each RFC's own header.

Anyone with first-hand knowledge of one of these decisions should move its row into the curated table above with the real rationale.

Spec version bump runbook

The repo currently hosts spec/v1/ rendered at /spec/v1/. Under v1.x compatibility rules the major version is the URL-stability boundary; minor bumps (v1.1, v1.2, …) edit spec/v1/ in place. A new major version (spec/v2/) materializes only when v2 work actually starts. This section is the runbook for that day.

Minor bump inside v1.x (the common case)

The release manager:

1. Lands the additive prose / schema / RFC content directly inside spec/v1/. Each touched file's status banner updates to the new minor: Status: Stable · v1.2 (YYYY-MM-DD). 2. Adds a ## [1.2.0] section to CHANGELOG.md. 3. Tags + publishes the release per PUBLISHING.md.

The public site is published from a separate repo — openwop/openwop-site renders this corpus, tracking openwop main pinned to an exact commit. The site (homepage hero, spec table, changelog, /spec/v1/, badges) re-renders and redeploys when openwop-site advances its OPENWOP_REF pin (its pin-bump workflow opens that PR daily as main moves; merging it deploys). No site steps, public/index.html edits, build-site.sh runs, or firebase deploy --only hosting:docs happen in this repo anymore.

Major bump to v2.x (rare)

Rewritten 2026-09-02 from the v2 charter's downstream audit: the earlier text pointed at site/src/build.mjs, which moved to the openwop-site repository in the 2026-06 split, and covered only the site. A major touches nine repositories. The release manager, in this order:

In this repository (openwop/openwop):

1. Creates spec/v2/ alongside spec/v1/ (spec/v2/core/ under the word budget the v2 RFC sets; spec/v2/ext/<name>/ for everything else, each with a witness class and maturity in its header). v1 stays in place and remains supported under COMPATIBILITY.md §5's host-inventory rule. 2. Creates schemas/v2/ with every $id under https://openwop.dev/spec/v2/. schemas/ (flat, v1 $ids) is left untouched and becomes read-only. 3. Regenerates api/openapi.yaml, api/asyncapi.yaml, api/grpc/openwop.proto (if the transport survives the cut) and the seams document from the v2 declaration file; the operation-path-manifest.json is regenerated for both operations and channels. 4. Enforces spec/v1/deprecations.json: every entry whose removeIn is 2.0 is absent from spec/v2/ and schemas/v2/, and the check script fails otherwise. 5. Publishes @openwop/openwop-conformance@2.0.0 per PUBLISHING.md (tarball contains dist, fixtures, vectors only; the v2 suite ships bundle v3 and the dual-major scenario). 6. CHANGELOG entry: ## [2.0.0] — the breaking-change-permitted release. Updates spec/v1/auth.md's status legend to reference both majors' legend pages.

In openwop/openwop-site:

7. Refactors site/src/build.mjs::buildSpecDocs() to iterate over spec/v/ instead of hard-coding spec/v1 (twelve sites at the time of writing, including a FATAL guard and the nav label): discover versions via readdirSync('spec').filter(d => /^v\d+$/.test(d)); render each at /spec/{version}/{slug}.html; render the highest version's index plus /spec/latest/; add an "Other versions" link slot. scripts/build-site.sh copies schemas/v2/ to public/spec/v2/ beside the v1 copy. 8. Updates firebase.json redirects: /spec/latest{,/:path} → /spec/v2/…; the /spec/v1.1{,/:path*} → /spec/v1/… entries stay.

In openwop/openwop-sdks:

9. Publishes @openwop/openwop@2.0.0 (npm), openwop-client==2.0.0 (PyPI), and the Go module under a /v2 directory (the module path has no version suffix today, so this is a directory move, not a tag; fix the stale sdk/smoke module path first). Old majors stay available for the PUBLISHING.md retention floor.

In openwop/openwop-registry:

10. Publishes registry/v2/ (re-signed manifests, or a signed compatibility overlay) and the peer-dependency alias table generated from the v2 declaration file. A v2 host treats an absent engines.openwop ceiling as <2.0.0.

In openwop/openwop-examples, openwop/openwop-cli:

11. The four reference hosts pass the 2.0.0 floor and commit fresh v3 bundles; the CLI's disposition (rewritten onto SDK 2, or frozen v1-only) is recorded in its README.

Hosts (INTEROP-MATRIX.md):

12. Each host advertises both majors via protocolVersions[] during the overlap, produces a non-vacuous v2 bundle, and gets a matrix row. The v1 deprecation date is then computed per COMPATIBILITY.md §5.

Anti-pattern. Do not create spec/v1.2/ as a directory. Inside v1.x, minor bumps are in-place edits of spec/v1/. A new directory is reserved for a new major version. The /spec/v1.1/ redirect entry in firebase.json exists only as an inbound-link safety net for citations that hard-coded the minor number; it does not imply a parallel directory.

See also

• GOVERNANCE.md — decision rules, role definitions, path to working group.
• RFCS/0001-rfc-process.md — formal RFC mechanism that maintainer approvals operate on.
• COMPATIBILITY.md — what counts as additive vs. breaking; what maintainers gate.
• CODE_OF_CONDUCT.md — behavioral expectations enforced under "Removal for cause."
• ROADMAP.md — the vendor-neutral-org migration tripwire that depends on this file.
• docs/recruitment/external-host.md — per-target host-recruitment outreach drafts.
• docs/recruitment/external-pack-author.md — external pack-author recruitment.