# Maintainers and Review Ownership

Dieses Repo ist so klein gehalten, dass eine schlanke Maintainer-Struktur sinnvoller ist als komplexe Freigaberegeln.

## Primaerer Maintainer

- `@johannes`

## Verantwortungsbereiche

- **Runtime / Compose / Netzlogik**
  - `compose.yaml`
  - `compose/`
  - `scripts/`
  - `systemd/`
- **Dokumentation / Betriebswissen**
  - `docs/`
  - `README.md`
  - `CHANGELOG.md`
  - `CONTRIBUTING.md`
  - `SECURITY.md`
- **Repository-Prozess in Gitea**
  - `.gitea/`
  - Release-Notizen
  - Issue- und PR-Triage

## Review-Regeln

Empfohlene Minimalregeln:

- Aenderungen an `compose.yaml`, `scripts/alanctl` oder Netz-Setup immer bewusst reviewen.
- Vor Merge von Infrastruktur-Aenderungen mindestens `./scripts/release-check` ausfuehren.
- Bei Aenderungen mit Betriebsfolgen zusaetzlich `./scripts/alanctl validate` und `./scripts/alanctl doctor` laufen lassen.
- Bei Update- oder Rollback-Aenderungen immer `CHANGELOG.md` und passende Doku mitziehen.

## CODEOWNERS-Hinweis

Dieses Repo enthaelt eine `CODEOWNERS`-Datei fuer Instanzen, die das unterstuetzen.
Falls deine Gitea-Version oder Konfiguration CODEOWNERS nicht automatisch auswertet, nutze diese Datei als dokumentierte Zustaendigkeitsmatrix und setze die Review-Regel organisatorisch ueber Pull Requests um.

## Praktischer Betrieb in kleinen Teams

Falls spaeter weitere Maintainer dazukommen, ist dieses Muster sinnvoll:

- `@johannes` als primaerer Owner fuer Runtime und Releases
- ein zweiter Owner fuer Dokumentation und Review
- sicherheitsrelevante Aenderungen nie ohne sichtbare Review-Notiz mergen