How Amber decisions become releases

Every contribution begins with an issue proposal prepared with a coding assistant and reviewed by its human contributor. GitHub holds proposals, field reports, decisions and showcase requests. Discord supports community conversation; actionable work returns to the issue.

Seth Tucker owns the current project direction, support claims and release tradeoffs. Maintainers agree on proposal scope, review behavior and evidence, and record the reason for accepting, changing, deferring or declining work. A release steward assembles the candidate, verifies identities and required receipts, publishes the approved artifacts, checks public origin and manages recovery. A delegate's release authority must be recorded explicitly.

The contributor owns the app need and acceptance. The assistant helps implement, test, document and prepare evidence. Release authority stays with the owner or a named delegate. Merge, issue closure and green checks supply evidence; the recorded release decision authorizes publication.

Record the proposal, decision author/time, intent, accepted scope, observable criteria, owning repository and rationale. The release adds its exact source/package identities, verified hashes, required gate roster, results, reviewer, approval, publication times and predecessor. Opt-outs keep their owner, reason and support effect visible.

The supported web foundation is release-gated. Preview capabilities retain separate criteria. Existing beta release receipts are dated evidence; each candidate must repeat its applicable compile, behavior, consumer, documentation, performance, supply-chain, publication and recovery checks.

The website publishes this owner direction. The named cross-repository maintainer roster, shared GitHub policy checks, and final V2 GA/graduation criteria still need adoption. The release contract records the remaining ecosystem work. Community participation follows the Code of Conduct.