Initial version of the Hermes self learning agent setup of JR IT Services.

docs/maintainers.md

@@ -0,0 +1,47 @@
+# 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