Files
chemenu/kb/concepts/Issue Label Scheme.md
T
torben 18ae28f918
CI / verify (push) Failing after 32s
Release / release (push) Successful in 38s
Chemenu 2.1.0 - deterministischer Wissenskompiler
Chemenu kompiliert Rohnotizen zu einem verlinkten, quellengebundenen Wiki:
raw/ -> types/ + tools/ -> kb/ -> reports/. Was mechanisch ist, macht
tools/wikitool; was Urteil braucht, macht ein Agent unter Contracts, deren
Grenzen in Code durchgesetzt sind statt im Prompt.

Dieser Commit ist der Startpunkt der oeffentlichen Historie. Die vorherige
Entwicklung fand in einer privaten Instanz statt und ist nicht Teil dieses
Repositorys; ihre Erzaehlung steht vollstaendig in CHANGES.md, das mit 44
Eintraegen von 0.1.0 bis 2.1.0 erhalten geblieben ist.

Der mitgelieferte Korpus ist ein Testbett und eine Demo: 170 Seiten ueber den
Stack selbst - Gates, Lint, Versionierung, Suche, das Wiki-Muster. Er
dokumentiert das Werkzeug mit den eigenen Mitteln des Werkzeugs.

Lizenz: AGPL-3.0 fuer den Stack (tools/, types/), CC-BY-4.0 fuer die Inhalte.
Die Grenze zwischen beiden ist der Dateiplan, den dist export berechnet -
siehe NOTICE.
2026-09-01 16:26:14 +02:00

6.0 KiB

type, concept_type, tags, created, modified, related, sources, confidence, confidence_base, provenance, summary
type concept_type tags created modified related sources confidence confidence_base provenance summary
types/concept.md decision
issues
gitea
triage
labels
backlog
2026-08-31 2026-08-31
Chemenu
Gitea MCP Server
KB Stack Versioning
Detect-Repair Asymmetry
Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31
0.70 0.70 sourced Zweiachsiges Pflicht-Labelschema fuer das Gitea-Board: prio/1..3 und size/XS..L, bewusst keine dritte Achse; die Regel liegt in instructions/dev/, weil sie keine ausgelieferte Instanz erreichen darf

Issue Label Scheme

Typ: Decision

Definition

Issue Label Scheme ist die Entscheidung, offene Arbeit an diesem Stack ausschließlich als Gitea-Issues zu führen und jedes Issue mit genau zwei Pflicht-Labels zu versehen: einer Priorität prio/1..3 und einer Größe size/XS..L. Eine dritte Achse gibt es bewusst nicht. Getroffen wurde die Entscheidung am 2026-08-31, gemeinsam mit der Löschung von TODO.md1 .

Priorität Bedeutung
prio/1 Blockiert oder beschädigt laufende Arbeit. Als Nächstes.
prio/2 Sammelt Zinsen. Eingeplant.
prio/3 Lohnend, wartet auf einen benannten Auslöser.
Größe Bedeutung
size/XS Minuten. Oft nur eine Entscheidung oder eine Beobachtung.
size/S Eine Sitzung, ein Publish, ein klarer Schnitt.
size/M Mehrere Dateien; eine Contract- oder Instruction-Änderung; eigener Testaufwand.
size/L Mehrere Sitzungen, oder offene Entwurfsfragen vor dem ersten Commit.

Die sieben Labels wurden angelegt und auf alle zehn zu dem Zeitpunkt offenen Issues angewandt1 .

Kernpunkte

  • Beide Achsen sind Pflicht, weil eine Priorität ohne Kosten eine halbe Entscheidung ist. Größe ist Aufwand und nicht Wichtigkeit, deshalb ist prio/1 size/XS das Beste, was auf einem Board stehen kann, und prio/3 size/L etwas, worüber gesprochen wird, bevor jemand anfängt.
  • prio/3 ist kein Friedhof. Der Auslöser muss im Issue benannt sein, sonst ist das Label ein höfliches Nein1 .
  • Keine dritte Achse. Art, Bereich oder Status wurden verworfen als der Punkt, ab dem eine Taxonomie eigene Pflege braucht. Das Board hat einen einzigen Betreuer.
  • Priorisiert wird nach Schaden, nicht nach Aufwand. Das Kriterium der ersten Triage lautete: was blockiert oder beschädigt laufende Arbeit. Ein Werkzeugfehler, der seinen Benutzer gegen eine Invariante des Stacks drückt, rangiert deshalb vor einer fehlenden Fähigkeit, so gut das Issue dazu auch geschrieben ist.
  • Ein Issue ohne Abnahmekriterium ist kein Arbeitspaket. Beim Portieren der Recherche-Notiz nach Issue #15 wurden Abnahmekriterien ergänzt, weil die Prosa-Notiz keine hatte1 .
  • TODO.md wurde gelöscht statt gepflegt. Ihr erster Abschnitt war ohnehin nur noch eine Linkliste auf Issues; der zweite, die Recherche-Notiz, ging vollständig nach #15. Danach gab es nichts mehr in der Datei, was nicht auf Gitea stand.

Wo die Regel liegt

Die Platzierung war die tragende Entscheidung, nicht das Schema selbst. README.md und AGENTS.md gehen in jede über wikitool dist export ausgelieferte Instanz, und eine solche Instanz hat kein Issue-Board auf gitea.nehmer.net. Eine dort mitgelieferte Label-Regel wäre eine Anweisung ins Leere.

instructions/dev/ ist der einzige Ort, der beides ist: von Agenten lesbar und nie ausgeliefert, weil dist export das Verzeichnis vollständig ausschließt. Das Schema steht deshalb in instructions/dev/issue-tracking.md und ist aus Schritt 2 des stack-dev-Skills verlinkt1 .

Aus demselben Grund war der Release ein PATCH (1.2.1) und kein MINOR: für eine bestehende Instanz ändert sich nichts. Das CI-Versions-Gate verlangte den Bump trotzdem, weil sein Muster auf instructions/ passt und instructions/dev/ darunter liegt1 . Siehe KB Stack Versioning.

Beispiele

  • Chemenu - das Repository, dessen Board nach dem Schema geführt wird; sieben Labels wurden angelegt und auf alle zehn offenen Issues angewandt
  • Gitea MCP Server - der Weg, auf dem Issues und Labels gelesen und geschrieben werden, da das Origin-Repository privat ist
  • Detect-Repair Asymmetry - Issue #14 ist der Fall, den dieses Concept beschreibt, und trägt prio/2 size/S

Wann zu verwenden

  • Auf einem Board mit einem einzigen Betreuer, das eine erkennbare Reihenfolge braucht, aber keinen Prozess.
  • Sobald offene Arbeit sonst in Prosa-Dateien wandert, die niemand als Board liest und die gegen den Tracker driften.

Wann NICHT zu verwenden

  • Nicht auf einem Board mit mehreren Teams, wo Zuständigkeit und Bereich echte Information tragen. Dann ist die dritte Achse keine Taxonomie-Pflege, sondern Routing.
  • Nicht als Ersatz für die Abnahmekriterien im Issue-Text. Die Labels ordnen ein Issue ein; ob es fertig ist, sagen sie nicht.
  • Nicht in einer ausgelieferten Instanz. Das Schema beschreibt das Entwicklungs-Repository und hat außerhalb davon keinen Gegenstand.

Verwandte Concepts

Beziehungen

Siehe auch

Fußnoten