Maintainers

The people who can approve and merge changes, and what each of them owns. How this list is joined and left is GOVERNANCE.md §4.

Active

Maintainer	Role	Areas
@nirmata78	Lead maintainer	Everything. Design authority for the contracts and the decision records
@HvorostenkoAlexander	Maintainer	Review across the repository, with the two-approval surfaces below

Two maintainers is the minimum that makes GOVERNANCE.md §2 real rather than aspirational: the contracts, the decision records and lock-api each require two approvals, and until now there was only one person who could give one.

The list is meant to keep growing. The project is deliberately structured — independent task specifications, authoritative contracts, a published dependency graph — so that people can contribute meaningfully without the lead maintainer in the loop on every decision.

Areas looking for an owner

These are the natural first ownership areas. Landing a few contributions in one of them is the shortest path to being asked to maintain it.

Area	What it covers	Entry points
Lock backends	lock-server/store.pg, lock-server/store.etcd, backend parity	T-011, T-030
Correctness harness	Deterministic simulation, linearizability, fault injection	T-043, T-044
Infrastructure	Terraform, Kubernetes, GKE Autopilot	T-050, T-051
Observability and SRE	Metrics, SLOs, alerts, runbooks, game day	T-060, T-068
Documentation	The doc set, the glossary, diagrams, the write-ups	T-073, T-074

Ownership of an area means reviewing pull requests that touch it and keeping its documentation true. It does not mean writing all of it yourself.

Emeritus

Nobody yet. When someone steps back they are listed here with thanks, and returning is a matter of asking.

---

Review routing is configured in .github/CODEOWNERS and should be updated in the same pull request that changes this file.