Governance¶
How AzureLocal/platform is governed — who decides what, how changes are proposed, and how versions roll out to the ~28 consumer repos.
Single-maintainer reality¶
The AzureLocal org is maintained by @kristopherjturner today. Governance is optimized around that: lightweight, written-down, automatable. ADRs are the substitute for meetings.
What this section covers¶
| Page | Topic |
|---|---|
| ADR process | When and how to write an Architectural Decision Record |
| Release cycle | Cadence; what triggers a release; release-please model |
| Versioning | SemVer policy for platform and its consumers |
| Breaking changes | What counts; deprecation windows; migration comms |
| CODEOWNERS & reviewers | Who reviews which paths; canonical CODEOWNERS |
Decision hierarchy¶
| Scope | Mechanism |
|---|---|
| Org-wide architecture | ADR in decisions/ |
| Standards content | PR on docs/standards/ or standards/ (propagates to consumers via sync) |
| Reusable workflow interface | PR + ADR if breaking; minor/patch otherwise |
| Templates | PR; new variant requires ADR |
| Day-to-day code | PR with Conventional Commits |
Communication¶
- Release notes — auto-generated by release-please from Conventional Commits. Read
CHANGELOG.md. - ADRs — canonical record of decisions.
decisions/README.mdindexes them. - Issues — platform issue tracker is the asynchronous backlog.
What platform doesn't govern¶
- Product-repo code quality (each repo's own CI enforces)
- Azure tenant configuration, RBAC, billing (out of scope)
- Community-health files in
AzureLocal/.github(see split rule)