# Governance

This document defines how the project is maintained and how decisions are made.

## Roles

- Users: use the library, report issues, request features.
- Contributors: open pull requests, improve docs/demos/tests.
- Triagers: help reproduce issues, label, close stale/unactionable items (no merge rights).
- Maintainers: merge rights, release rights, set technical direction.

## Decision Making

We use "lazy consensus" by default:
- If there is no sustained objection, a maintainer may merge.

For changes that affect the stable API surface or SemVer guarantees:
- require 2 maintainer approvals (or 1 approval + 1 week with no objections)
- require a `CHANGELOG.md` entry
- require tests (unit/integration/regression) or a reproducible benchmark justification

## Becoming a Maintainer

Typical path:
- consistent high-quality contributions
- demonstrated care for backwards compatibility and tests
- participation in triage (closing loops)

New maintainers are added by existing maintainers after a public proposal and a 7-day comment window.

## Triage Policy

See `TRIAGE.md` for labels, severity, and response targets.

## Releases

Release process is documented in `RELEASING.md` and automated via GitHub Actions workflows in `.github/workflows/`.

## Project Assets

- Roadmap: `ROADMAP.md` (public, living)
- Maintenance policy: `MAINTENANCE.md`
- Code of Conduct: `CODE_OF_CONDUCT.md`
- Security: `SECURITY.md`
- Support channels: `SUPPORT.md`
