From 49faf20243ca14f09e39e2b547a677b3031504e5 Mon Sep 17 00:00:00 2001 From: Thore Cimbal Date: Thu, 30 Jul 2026 12:00:00 +0000 Subject: [PATCH] =?UTF-8?q?README:=20Konventionen=20bereinigen=20und=20L?= =?UTF-8?q?=C3=BCcken=20schlie=C3=9Fen?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Stale K3S-01-Beispiel entfernt (hosts/k3s.md existiert seit 1c5e21c nicht mehr) - Neuer Status "verworfen" fuer bewusst nicht umgesetzte Punkte, getrennt von "erledigt" - Explizite Konvention: Gegenstuecke in anderen Host-Dateien beim Schliessen mitaktualisieren, nicht nur verlinkt stehen lassen - Neuer Abschnitt "Verhaeltnis zu Gitea-Issues": Faustregel, wann etwas nur als Issue, nur hier, oder als Eintrag mit Issue-Verweis landet Co-Authored-By: Claude Sonnet 5 --- README.md | 47 +++++++++++++++++++++++++++++++++++++---------- 1 file changed, 37 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index f2a747d..285c0d3 100644 --- a/README.md +++ b/README.md @@ -33,9 +33,12 @@ auf CFGMON, dessen Ursache ein blockierter Port auf dem Gameserver ist, gehört ## Konventionen **IDs** sind pro Datei fortlaufend mit einem Präfix, das den Ort benennt: -`CFGMON-01`, `GAME-01`, `MATRIX-01`, `K3S-01`, `ZONE-01`. IDs werden **nicht -wiederverwendet** — ein erledigter Punkt behält seine Nummer, damit Querverweise und -Commit-Messages dauerhaft stimmen. +`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. 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 @@ -49,22 +52,46 @@ Fachbegriff vor. | `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 Punkte werden **nicht gelöscht**, sondern auf `erledigt` gesetzt und nach -unten in den Abschnitt „Erledigt" verschoben. Der Grund: bei mehreren Hosts ist die -Frage „haben wir das damals eigentlich gemacht, und warum so?" häufiger als die -Frage „was ist noch offen". +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 verifiziert -ist, wird das dazugeschrieben — eine unbestätigte Vermutung, die wie ein Befund -aussieht, kostet beim nächsten Mal mehr Zeit als sie spart. +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. + ## 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 Gitea-Issues + +Manche Projekt-Repos (z. B. `sorb/axion1337.chat-gitops`) führen ihren eigenen +Feature-/Fix-Backlog als Gitea-Issues — 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): + Gitea-Issue im jeweiligen Projekt-Repo, 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.