Maintainer expectations
Set review, release, security, conflict, and documentation responsibilities for project maintainers.
Maintainers protect the product's working path and the trust of contributors. Merge authority does not replace evidence: a maintainer must apply the same architecture, security, generated-contract, and release gates required of a contributor.
Review responsibilities
Review the user or operator outcome, owning path, dependency direction, generated sources, normal and failure behavior, integration edge, recovery path, and public-tree impact. Ask for a smaller change when scope obscures proof. Preserve unrelated work and do not accept a compatibility layer, speculative service, or duplicate source of truth for convenience.
Treat delegated reports, screenshots, scanner output, and passing unit tests as claims to verify at the appropriate boundary. User-facing changes require reachable browser and accessibility evidence. Security claims require negative tests at the real trust boundary. Performance claims require the committed fixture, environment, raw measurements, and unchanged budget.
Release responsibilities
Maintain locked dependency and tool versions, generated-contract drift checks, migration safety, notices and provenance, full-history secret scanning, public-content review, and rollback evidence. Keep a previous known-good artifact or image until live smoke and rollback checks pass. Do not weaken a gate, upgrade a paid plan, disable a spend cap, or mutate an unrelated provider resource to complete a release.
When a provider credential is unavailable, finish the adapter, deterministic contract and failure tests, unconfigured product state, documentation, and deployment wiring. Record only the live smoke as an activation gate; do not imply that it passed.
Security and community responsibilities
Keep vulnerability and conduct reports private, minimize collected personal information, and avoid conflicts of interest. A maintainer named in a conduct report must not decide it alone. Coordinate security fixes and disclosure with the reporter when safe, and preserve access-controlled incident evidence outside public issues and artifacts.
Enforce the code of conduct consistently and explain technical decisions in plain, evidence-backed terms. Disagreement about implementation is not misconduct; harassment, intimidation, and manipulation of evidence are.
Current pre-release limits
The project does not yet publish maintainer rotation, quorum, funded support, or response-time guarantees. Before public release, repository settings and public policy must make the active private security-reporting path and current maintainers discoverable. Until a broader governance policy is adopted, do not infer authority or service commitments beyond the repository's canonical policy files.
Maintainers should review durable decisions before changing a long-lived boundary and release guidance before publishing artifacts.