sorb/management
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Framework-Umbau: Backlogs wird management-Repo (ADR-0005, Kanban + Scrum-Elemente)

Browse Source 
- decisions/: ADR-Verzeichnis mit Template + 0001-0005 (git.lab-Kanonik,
  Lab-Cutover, CVE-Meldeweg, Site-to-Site-VPN-Design, Framework-Wahl)
- vision/: je eine Vision fuer Community/Tool/Plattform (Entwuerfe)
- roadmap.md: Linien, Meilenstein-Kandidaten, Kadenz
- hosts/+shared/: offene Punkte -> Issues #1-#12 im management-Projekt
  (IDs bleiben in den Titeln), Dateien halten Bestand + Historie
- README: Framework, Board/status-Labels (WIP-Limit 2), Topologie

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
This commit is contained in:
Thore Cimbal
2026-08-01 12:00:00 +00:00
co-authored by Claude Fable 5
parent 0f3f155bc5
commit fdf30d42e1
18 changed files with 429 additions and 523 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+56 -112
View File
@@ -1,131 +1,75 @@
# Backlogs
# management
Zentrale Sammlung offener Punkte über alle Hosts und Dienste hinweg. Ein Eintrag
landet hier, wenn er bewusst nicht sofort erledigt wurde — damit er nicht in einer
Chat-Historie oder einem Kopf verschwindet.
Steuerungs-Repo für alles über den einzelnen Projekten: Visionen, Roadmap,
Entscheidungen (ADR), Arbeitsverfahren, AARs — und der Bestand der Hosts.
Framework: **Kanban-Rückgrat mit leichten Scrum-Elementen**, begründet und
im Detail festgelegt in [ADR-0005](decisions/0005-pm-framework-kanban.md).
*(Bis 2026-08-01 hieß dieses Repo `Backlogs` und führte offene Punkte als
Markdown — die leben jetzt als Issues, siehe unten.)*
## Repo-Topologie (seit 2026-08-01)
**Kanonisch lebt dieses Repo auf `git.lab`** (`axion1337.chat/Backlogs`, nur im
Lab bzw. via VPN erreichbar — das Lab ist die Quelle der Wahrheit).
`rohana.axion1337.de/sorb/Backlogs` ist ein **Push-Mirror**: git.lab überschreibt
ihn bei jedem Push per Force. Deshalb **nie direkt zu Gitea pushen** — solche
Commits gehen beim nächsten Mirror-Lauf verloren (Rettung: `.patch` von Gitea
ziehen + `git am`, siehe [Kanonisierung](verfahren/deploy-uebergabe.md)).
**Kanonisch lebt dieses Repo auf `git.lab`** (`axion1337.chat/management`, nur im
Lab bzw. via VPN erreichbar — das Lab ist die Quelle der Wahrheit,
[ADR-0002](decisions/0002-issues-und-management-ins-lab.md)).
`rohana.axion1337.de/sorb/management` ist ein **Push-Mirror**: git.lab
überschreibt ihn bei jedem Push per Force. Deshalb **nie direkt zu Gitea
pushen** — solche Commits gehen beim nächsten Mirror-Lauf verloren (Rettung:
`.patch` von Gitea ziehen + `git am`, siehe
[Kanonisierung](verfahren/deploy-uebergabe.md)).
**Eine bewusste Ausnahme:** Die **Deploy-Übergabe-Issues** laufen weiter auf dem
Gitea-Mirror (dortiger Issue-Tracker), weil CFGMON und andere Hosts außerhalb
des Labs `git.lab` nicht erreichen — eine Übergabe muss aber von beiden Seiten
lesbar/kommentierbar sein.
**Eine befristete Ausnahme:** Die **Deploy-Übergabe-Issues** laufen auf dem
Gitea-Mirror-Tracker, weil CFGMON und andere Hosts außerhalb des Labs `git.lab`
noch nicht erreichen. Abgelöst wird das durch das Site-to-Site-VPN
([ADR-0004](decisions/0004-site-to-site-vpn-hetzner-lab.md),
[Issue #12](https://git.lab/axion1337.chat/management/-/issues/12)).
## Aufbau
## Struktur
```
hosts/ ein File pro Host, benannt nach dem Hostnamen
shared/ Themen, die mehrere Hosts betreffen (DNS-Zone, Mail-Policy)
verfahren/ wiederkehrende Abläufe zwischen Personen und Hosts, plus AARs
```
Faustregel für die Einordnung: **Der Eintrag gehört dorthin, wo die Arbeit
stattfindet, nicht dorthin, wo das Symptom auftritt.** Ein down-Target in Prometheus
auf CFGMON, dessen Ursache ein blockierter Port auf dem Gameserver ist, gehört nach
`hosts/game.md` — mit Querverweis von CFGMON.
## Hosts
| Host | Adressen | Rolle | Backlog |
|---|---|---|---|
| **CFGMON** | `188.245.193.243`, `2a01:4f8:c17:93eb::1`, privat `10.0.0.3` | Monitoring-Stack, Gitea, Traefik | [hosts/cfgmon.md](hosts/cfgmon.md) |
| **game** | `157.90.155.206` (`game.axion1337.de`) | Pterodactyl / Gameserver | [hosts/game.md](hosts/game.md) |
| **matrix** | `49.13.132.245` (`matrix.axion1337.de`) | Matrix-Homeserver | [hosts/matrix.md](hosts/matrix.md) |
| **Overmind** | `10.58.73.17` (`git.lab`, **nur im Homelab auflösbar**) | GitLab + CI-Runner (Lab) | [hosts/overmind.md](hosts/overmind.md) |
## Übergreifend
| Thema | Backlog |
| Pfad | Artefakt |
|---|---|
| DNS-Zone `axion1337.de` und Mail-Policy (IONOS) | [shared/zone-axion1337.md](shared/zone-axion1337.md) |
| `vision/` | Eine Vision je Linie: Community (axion1337.chat), Tool (ThreadNet), Plattform (Homelab) |
| `roadmap.md` | Linien, Meilenstein-Kandidaten, Kadenz — GitLab-Milestones halten den Stand |
| `decisions/` | ADRs — Pflicht bei Architekturentscheidungen **und dauerhaften Ausnahmen** |
| `verfahren/` | Wie wir arbeiten: [Deploy-Übergabe/DoD](verfahren/deploy-uebergabe.md), [AARs](verfahren/aar/), Werkzeuge |
| `hosts/`, `shared/` | **Bestand + Historie** je Host/Thema — offene Punkte sind Issues |
## Verfahren
## Das Backlog: Issues + Board
`hosts/` und `shared/` halten **offene Punkte**, [verfahren/](verfahren/) hält
**wie wir arbeiten** — Abläufe, die zwischen Personen oder über mehrere Hosts
hinweg gelten und deshalb an kein einzelnes Projekt-Repo gehören.
Alle offenen Punkte sind **Issues in diesem Projekt** (host-/infra-Scope, mit
`host:`-Labels; die alten IDs wie `CFGMON-01` bleiben im Titel) bzw. in den
Produkt-Projekten der Gruppe (Projekt-Scope). Das
**[Gruppen-Board](https://git.lab/groups/axion1337.chat/-/boards)** zeigt alles
über die `status:`-Labels:
| Verfahren | Inhalt |
|---|---|
| [Deploy-Übergabe](verfahren/deploy-uebergabe.md) | „einer baut, ein anderer rollt aus": Issue-Vorlage, Prüfliste, AAR |
| Label | Bedeutung | Policy |
|---|---|---|
| *(keins)* | Backlog | wird im Refinement gesichtet |
| `status:next` | als Nächstes gezogen | die einzige „Zusage" (Pull nach Kapazität) |
| `status:doing` | in Arbeit | **WIP-Limit: max. 2** |
| `status:wartet` | blockiert | nur mit benanntem Grund im Issue |
Zur Deploy-Übergabe gehört die Issue-Vorlage
`.gitea/ISSUE_TEMPLATE/deploy-uebergabe.yaml` — sie erscheint beim Anlegen eines
Issues in diesem Repo als **Deploy-Übergabe**. Die Übergabe-Issues laufen auf dem
**Gitea-Mirror** (siehe Repo-Topologie oben: CFGMON erreicht git.lab nicht), weil
das Verfahren repo-übergreifend gilt; der fachliche Inhalt bleibt im jeweiligen
Projekt-Repo.
Genau **ein** `status:`-Label pro Issue. Prioritäten weiter über `priority:*`.
## Konventionen
## Konventionen (unverändert gültig)
**IDs** sind pro Datei fortlaufend mit einem Präfix, das den Ort benennt:
`CFGMON-01`, `GAME-01`, `MATRIX-01`, `ZONE-01` — ein Präfix pro Datei in `hosts/`
bzw. `shared/`, keine Liste losgelöst vom tatsächlichen Datei-Bestand. IDs werden
**nicht wiederverwendet** — ein erledigter Punkt behält seine Nummer, damit
Querverweise und Commit-Messages dauerhaft stimmen. Auch wenn eine ganze Datei
entfällt (siehe `hosts/k3s.md`, entfernt 2026-07-30), wird ihr Präfix nicht für
etwas anderes wiederverwendet.
**IDs** (`CFGMON-01`, `ZONE-01`, …) werden **nie wiederverwendet**; sie leben in
Issue-Titeln weiter. Neue host-/infra-Punkte bekommen die nächste freie Nummer
ihres Präfixes als Issue.
Das Präfix für DNS-Themen ist bewusst `ZONE-` und nicht `DNS-`: `DNS-01` ist der
Name eines ACME-Challenge-Typs und käme in genau diesen Backlogs ständig als
Fachbegriff vor.
**Jeder Punkt braucht** eine Beschreibung des tatsächlichen Zustands und einen
konkreten nächsten Schritt; nicht selbst Verifiziertes wird als solches markiert
(woher stammt die Aussage?). **Zeitkritisches** bekommt ein Datum, nicht „bald".
**Status:**
| Wert | Bedeutung |
|---|---|
| `offen` | noch nicht angefasst |
| `in Arbeit` | läuft gerade |
| `wartet auf …` | blockiert, mit Angabe worauf |
| `erledigt` | fertig, mit Datum — Eintrag bleibt stehen, siehe unten |
| `verworfen` | bewusst **nicht** umgesetzt, mit Datum und Begründung — nicht dasselbe wie `erledigt`: es ist nichts passiert, sondern es wurde entschieden, es zu lassen |
Erledigte **und** verworfene Punkte werden **nicht gelöscht**, sondern nach unten
in den Abschnitt „Erledigt" verschoben (verworfene Punkte darin klar als solche
kennzeichnen). Der Grund: bei mehreren Hosts ist die Frage „haben wir das damals
eigentlich gemacht, und warum so — oder haben wir es bewusst gelassen?" häufiger
als die Frage „was ist noch offen".
**Jeder Eintrag braucht** einen Status, eine Beschreibung des tatsächlichen
Zustands, und einen konkreten nächsten Schritt. Wenn eine Aussage nicht direkt
verifiziert ist (aus einer Konsole, einer Doku, einer Ableitung statt einer
Messung von dem betroffenen System selbst), wird kurz dazugeschrieben, woher sie
stammt — eine unbestätigte Vermutung, die wie ein Befund aussieht, kostet beim
nächsten Mal mehr Zeit als sie spart.
**Zeitkritisches** bekommt ein Datum in der Statuszeile, nicht nur „bald".
**Gegenstücke in anderen Host-Dateien** (z. B. ein Punkt, der von zwei Seiten
beschrieben wird, wie ein Push von `matrix` auf einen offenen Port bei `CFGMON`)
werden beim Schließen einer Seite **auf der anderen Seite mitaktualisiert**, nicht
nur verlinkt und stehen gelassen — sonst bleibt eine Seite unbemerkt veraltet.
**Erledigtes und Verworfenes** bleibt sichtbar: Issues werden geschlossen (nicht
gelöscht), `verworfen` wird im Schlusskommentar begründet — der Unterschied
zwischen „gemacht" und „bewusst gelassen" ist die häufigste Rückfrage.
## Verhältnis zu den Projekt-Repos
Dieses Repo hält die offenen Punkte. Die **Konfiguration** liegt weiter in den
jeweiligen Projekt-Repos, z. B. `sorb/threadnet-operating` für den
Monitoring-Stack auf CFGMON. Damit nichts doppelt geführt wird, verweisen die
Projekt-Repos hierher statt eigene Backlog-Dateien zu pflegen.
## Verhältnis zu Projekt-Issues
Die Projekt-Repos führen ihren eigenen Feature-/Fix-Backlog als Issues — **seit
2026-08-01 auf git.lab** (Migration per gitops#48, alte Gitea-Issues tragen einen
Verweis auf ihr GitLab-Gegenstück). Das bleibt dort, wird hier **nicht**
dupliziert. Faustregel für die Abgrenzung:
- **Reiner Projekt-Scope** (eine Funktion in einem Repo, ein Bug in einem Service):
Issue im jeweiligen Projekt auf git.lab, kein Eintrag hier.
- **Host-/Infrastruktur-Scope** (betrifft einen Host direkt, oder eine Entscheidung
über mehrere Hosts/Repos hinweg, z. B. wo ein CI-Runner laufen soll): Eintrag
hier, mit Verweis auf betroffene Issues statt deren Inhalt zu wiederholen.
- **Beides zugleich** (ein Host-Thema hat ein konkretes Gegenstück als Issue, z. B.
ein fehlender Gitea-Runner blockiert CI in mehreren Repos): kurzer Eintrag hier
mit Link zum führenden Issue, statt den Issue-Inhalt hierher zu kopieren.
Konfiguration lebt in den Projekt-Repos (z. B. `threadnet-operating` für den
CFGMON-Stack), reine Projekt-Bugs/-Features in deren Issues auf git.lab.
Hierher gehört, was mehrere Hosts/Repos betrifft oder eine Entscheidung ist.
Ein Punkt, der von zwei Seiten beschrieben wird, verlinkt die andere Seite und
wird beim Schließen **dort mitaktualisiert**.