Governance

Garnet is small and this page says so. Pretending to have a foundation and a voting council would be the opposite of the project's stated values.

Who decides

Garnet is maintained by Island Development Crew (Jon Isaac, maintainer). Final decisions on language design, releases, and what merges are the maintainer's, exercised through the Island-Dev-Crew GitHub organization. There is no separate steering committee; claiming one would be fiction.

How a change lands

1. Work happens on a branch in a fork (e.g. Navigata1/garnet).
2. A pull request is opened against Island-Dev-Crew/garnet main.
3. It must pass the dogfood-readiness gate: local verification, evidence in the PR body, a Desktop evidence bundle, and explicit deferred/out-of-scope claims. The gate rejects an unqualified "production ARC complete" claim.
4. The maintainer (org-owner account) reviews and merges. CI and the readiness ledger must stay consistent.

Proposing larger changes RFC: IN USE

Substantive changes go through a written RFC before implementation: any change to the language grammar or semantics, to the capability model (@caps, the manifest, diff-caps, seal), to stability-tier promotion/demotion policy, or any new edition or backwards-incompatible change. Bug fixes, docs, tests, and small additive features do not need one — a PR with green CI and dogfood evidence is enough.

An RFC is authored from rfcs/0000-template.md, numbered with the next free integer as NNNN-short-title.md, and opened as a pull request. It moves through Draft → Discussion → Accepted | Rejected | Withdrawn, and the maintainer records the decision and its rationale in the RFC's Status field. An accepted RFC authorizes implementation slices; it is not itself an implementation, and acceptance is not a readiness or production claim.

Final comment period. When discussion converges, the maintainer proposes FCP with a disposition — merge, close, or postpone — for 10 calendar days, announced on the RFC's tracking PR. Any substantial new argument cancels FCP and returns the RFC to Discussion; a clean FCP executes the disposition. With one maintainer, FCP is a self-imposed cooling-off period rather than a vote. It moves no authority: releases and tags stay outside RFC scope.

Two RFCs exist today, in rfcs/:

• RFC-0001, a cross-language capability-manifest standard — Draft. It is an intent and a draft, not an accepted standard; no external body has reviewed or adopted anything.
• RFC-0002, integer arithmetic checked by default — Accepted, and implemented for +, -, * and unary -. The explicit wrapping escape hatch remains deferred.

The full process, including the edition mechanism for backwards-incompatible changes, is in GOVERNANCE.md. For a question that is not yet an RFC, open a thread in GitHub Discussions.

Conduct & security

Contribution is governed by the Code of Conduct. Security issues follow the disclosure path in SECURITY.md — not public issues.

Verified today / Still open

This is single-maintainer governance for a research-grade prototype. It is enough to evaluate the project's decision path; it is not a claim of institutional permanence. As contributors arrive, this document changes with the reality, not ahead of it.