Zusammenfassung

  • Der Tools Update vom August 2026 nennt Tausende offene GitHub-Issues, darunter als Beispiel rund 1.100 für Datatracker. Fast alle seien einzelne Einträge ohne Arbeitsstruktur und ohne Aufwands- oder Prioritätsbewertung.
  • Der neue Ablauf ordnet sie als Goal -> Project -> Epic -> Task, schätzt die untersten Tasks und setzt anschließend eine erste Priorität auf Goal- und Project-Ebene, bevor ein noch nicht festgelegtes Community-Verfahren folgt.
  • Ein öffentliches Issue beweist die Aufnahme einer Meldung, nicht deren Validierung, Annahme, Finanzierung, Terminierung, Umsetzung oder Billigung durch die IETF.
  • Ein öffentlicher Issue-zu-Roadmap-Beleg kann Zustände und Zuständigkeiten zeigen, ohne internes ZenHub, Sicherheitsdetails, Vertragsdaten oder persönliche Leistungsinformationen offenzulegen.

Das Datum eines Issues ist keine Wartemarke

Backlogs sehen auf den ersten Blick wie Warteschlangen aus. Jeder Eintrag hat eine Nummer und ein Datum. Daraus folgt aber keine Reihenfolge. Ein altes Issue kann überholt oder doppelt sein. Ein neues kann eine akute Betriebsgefahr betreffen. Eine sichtbare Funktion kann wenig Entwicklungsarbeit, aber dauerhaft hohe Betriebskosten verursachen. Eine unscheinbare Migration kann Voraussetzung für viele andere Vorhaben sein.

Datatracker-Issue #9204 liefert ein anschauliches Beispiel. Es verlangt, die Rolle als Designated Expert auf einer persönlichen Datatracker-Seite abzubilden. Zum Recherchezeitpunkt war es öffentlich open; assignee, project, milestone, relationship, branch und pull request waren leer. Diese Leerstellen belegen keine Untätigkeit. Sie belegen nur, dass der öffentliche GitHub-Zustand keinen vollständigen institutionellen Pfad zeigt.

Der Augustbericht beschreibt die verdeckte Zerlegung. Für IANA kann zunächst eine API-Spezifikation nötig sein. Das Datenmodell muss unterschiedliche Formen von Designated Experts abbilden: eine Person, eine Area-Director-Rolle, eine Liste oder eine Gruppe von Chairs. IANA- und Datatracker-Daten müssen abgeglichen und anschließend laufend über die API importiert werden. Aus einer scheinbar kleinen Anzeigeänderung wird ein Project mit mehreren Epics unter einem Goal zur genauen und umfassenden Abbildung des Standardisierungsprozesses, seiner Rollen und Beiträge.

Darum sind rund 1.100 Issues nicht rund 1.100 ausführungsreife Tasks. Die Zahl beschreibt den Umfang der Sichtung im August. Sie sagt nicht, dass jeder Eintrag gültig, eigenständig, aktuell oder breit gewünscht ist.

Zwischen open und closed liegen mehrere Entscheidungen

Ein geregelter Backlog braucht mehr als zwei Zustände. Intake hält fest, was wann gemeldet wurde. Triage unterscheidet Klärungsbedarf, Bestätigung, Duplikat, Ersetzung, fehlenden Zuständigkeitsbereich und geschützte Sicherheitsfälle. Klassifikation verbindet den Eintrag mit Goal, Project, Epic und Task. Schätzung untersucht Aufwand und Abhängigkeiten. Priorisierung vergleicht Alternativen. Ressourcenfreigabe erlaubt Kapazität oder Ausgaben. Roadmap, Umsetzung, Release, Korrektur und Abschluss folgen.

Diese Schritte haben verschiedene Beweise und verschiedene Träger von Autorität. Der Melder kennt die konkrete Beeinträchtigung, kann aber kein Budget binden. Ein Entwickler kennt technische Abhängigkeiten, entscheidet aber nicht allein über Strategie. Das Tools Team kann einen ersten Prioritätsentwurf erstellen, ohne technischen IETF-Konsens zu erzeugen. Community-Feedback kann Gründe verändern, ohne selbst ein Budgetvotum zu sein.

Bleiben all diese Schritte hinter open verborgen, wirkt der Eintrag wie eine schwache Zusage. Antwortet die Institution lediglich, ein Issue sei keine Zusage, bleibt die berechtigte Statusfrage offen. Noch nicht geprüft, bestätigt und zurückgestellt, in ein anderes Project übernommen, außerhalb des Mandats und vergessen sind nicht dasselbe.

Schon die alte Roadmap scheiterte an der Verbindung

Im Dezember 2025 erläuterte das Tools Team den Rückzug einer früheren Roadmap. Mehrquartalsprojekte waren in Phasen zerlegt worden, ohne deren Inhalt klar zu machen. Organisatorische Goals standen neben detaillierten Projects. Vor allem fehlte die Verknüpfung zwischen Roadmap-Projekten und den einzelnen GitHub-Issues in den Tool-Repositories.

Das Ersatzmodell nutzte ein vom Tools Team gepflegtes, nur lesbares GitHub-Projekt. Es trennte Goals von Projects und fragte die Community, ob die Struktur nützlich sei, ob die Ebenen Planung verständlich und beeinflussbar machten und ob die richtigen Vorhaben für 2026 gewählt worden seien. Read-only ist hier kein Widerspruch zur Beteiligung: Der offizielle Plan kann vor beliebigen Änderungen geschützt und zugleich kommentierbar sein.

Im Februar vermerkte der öffentliche Bericht des Executive Director eine relativ geringe Beteiligung am Roadmap-Termin. Die Anwesenden unterstützten den Ansatz; breitere Beteiligung bleibe nötig. Aus niedriger Teilnahme folgt weder Ablehnung noch ein repräsentatives Mandat, weil der relevante Nenner unbekannt ist.

Im März fragte ein Teilnehmer, wo er sehen könne, ob ein für Q1 vorgesehenes Vorhaben im Plan oder im Rückstand sei. Eine einzelne Frage ist kein Community-Konsens. Sie benennt aber die fehlende Verbindung zwischen Zielzeitraum und aktuellem Zustand.

Im April wurde die Roadmap-Arbeit zugunsten der Modernisierung des RFC Production Center zurückgestellt. Im Juni war sie weiter unverändert; Planung und Community-Beteiligung sollten beim Retreat Mitte Juni beraten werden. Das belegt keinen Abbruch. Es zeigt eine reale Prioritätskonkurrenz: Ein mehrjähriges operatives Vorhaben kann Kapazität beanspruchen, die sonst in das Planungssystem selbst fließt.

Drei Phasen, drei unterschiedliche Aussagen

Phase 1 klassifiziert. Für drei Wochen nach der IETF 126 in Wien wollte das Team offene Issues prüfen und als Goal -> Project -> Epic -> Task ordnen. Der größte Teil sollte in einer für die Community unsichtbaren ZenHub-Instanz stattfinden, aber mit öffentlichen Repositories verknüpft werden. Dringendes kann dabei erkannt werden; die meisten Issues werden zu diesem Zeitpunkt noch nicht geschätzt oder priorisiert. Der Bericht hält einen weiteren Sprint ausdrücklich für möglich.

Phase 2 schätzt. Der wahrscheinlichste Implementierer bewertet den Aufwand des untersten Tasks. Das Team kalibriert per estimation poker, summiert nach oben und teilt zu große Tasks. Eine solche LoE-Angabe ist weder individuelle Leistungsnote noch Kapazitätsreservierung oder Liefertermin.

Phase 3 bildet Priorität. Sie soll grundsätzlich auf Goal- und Project-Ebene liegen. Das Tools Team erstellt einen ersten Entwurf und öffnet ihn anschließend für Community-Feedback. Am 6. August stand dessen Verfahren noch nicht fest. Der Entwurf ist deshalb kein Community-Mandat, und späteres Feedback darf nicht als Volksabstimmung beschrieben werden.

Klassifiziert heißt nicht angenommen. Geschätzt heißt nicht eingeplant. Ein prioritäres Project macht nicht jeden untergeordneten Task bereit. Ein Roadmap-Ziel ist keine technische Norm. Gerade diese Trennungen verhindern, dass öffentliche Sichtbarkeit in falsche Verbindlichkeit umschlägt.

Evidenz statt Beliebtheitsabstimmung

Die IETF-Tools tragen Dokumente, Working Groups, Reviews, Ballots, Meetings, Mail und RFC-Aufzeichnungen. Nutzer sehen Reibungsverluste, die im Betriebsteam nicht automatisch sichtbar sind. Das frühere Tools Architecture and Strategy Team sollte deshalb breit konsultieren, während Umsetzung, Wartung und Betrieb einzelner Tools beim Tools Team blieben.

Ein offener Kanal erzeugt jedoch keine repräsentative Wählerschaft. Wer einen Workaround gefunden hat, meldet sich möglicherweise nicht mehr. Sicherheitswartung, Framework-Migration und Datenabgleich sammeln weniger Reaktionen als eine sichtbare Funktion. Eine Sortierung nach Kommentaren belohnt Lautstärke und Aufmerksamkeit, nicht zwingend Schaden und Kontinuität.

Feedback sollte daher Evidenzklassen abfragen: betroffener Workflow, Häufigkeit, Schwere, betroffene Rollen, Workaround, Kontinuitätsfolge, externer Termin und Quelle. Die Antwort kann lauten: neu klassifiziert; angenommen, aber zurückgestellt; durch ein anderes Project abgedeckt; außerhalb des Umfangs; aus Sicherheitsgründen eingeschränkt; oder unverändert, jeweils mit begrenzter Begründung.

So erhält die Community wirksamen Einfluss, ohne dass Reactions, Mailmenge oder Sitzungsteilnahme direkt über Engineering-Kapazität entscheiden.

Der öffentliche Dispositionsbeleg

Der Beleg beginnt mit Quell-Issue und Erstellungsdatum. Er ergänzt letztes Triage-Datum und verantwortliche Teamrolle sowie einen eindeutigen Gültigkeitszustand: Klärung nötig, bestätigt, Duplikat, ersetzt, außerhalb des Umfangs, sicherheitssensibel oder geschlossen.

Soweit sicher, folgen Links zu öffentlichen Goal-, Project-, Epic- und Task-Kennungen sowie Abhängigkeits- und Blockerklassen. Aufwand erscheint als Band mit Datum und Sicherheit. „Noch nicht geschätzt“ ist ein ehrlicher Zustand. Ein leeres Feld ist es nicht. Priorität erhält Klasse, Datum, aktuellen Autoritätsträger und knappen Grund oder „noch nicht priorisiert“.

Die Beteiligungsschicht nennt Fenster, Kanal, gewünschte Evidenz, Grenzen des Nenners und die Disposition der Beiträge. Nicht jede Nachricht oder Person muss veröffentlicht werden; die institutionelle Antwort muss aber zurechenbar sein.

Roadmap-Zustand und Zielkorridor erscheinen erst nach tatsächlicher Freigabe. Links zu Umsetzung, Release, Abschluss, Ersetzung und Korrektur vervollständigen später die Kette. Korrekturen ergänzen oder ersetzen einen Zustand, ohne die Geschichte still zu löschen.

Der Beleg muss aus dem Planungssystem projiziert werden. Eine weitere handgeführte Liste würde GitHub, ZenHub und öffentliche Roadmap in drei auseinanderlaufende Wahrheiten verwandeln.

Was nicht öffentlich werden muss

Rechenschaft verlangt keinen vollständigen ZenHub-Zugang. Interne Notizen können vorläufige Bewertungen, Schwachstellen, Exploit-Wege, Personendaten, Vertragsbedingungen und individuelle Auslastung enthalten. Namentliche Schätzungen als Leistungsmaß würden defensives Aufblähen fördern.

Ein geschütztes Issue kann den eingeschränkten Status, die nächste verantwortliche Rolle und den Zeitpunkt eines sicheren Updates nennen, ohne die Lücke offenzulegen. Eine Vertragsabhängigkeit kann als Beschaffungs- oder Fremddienstblocker erscheinen. Öffentlich wird das teamkalibrierte Band, nicht das Urteil über einen einzelnen Entwickler.

Der Beleg verteilt auch keine Autorität neu. Das Tools Team behält den ersten Prioritätsentwurf. Executive Director und IETF LLC behalten administrative, vertragliche und ressourcenbezogene Zuständigkeiten; der Board überwacht strategisch. Die Community liefert Evidenz und hinterfragt Gründe. Technische Standardautorität bleibt im IETF-Verfahren. Der Beleg dokumentiert diese Grenzen.

Quellen

  1. August Tools Update
  2. Introducing a new roadmap framework
  3. Public Executive Director Report, 18 February 2026
  4. March tools update discussion
  5. IETF tools update 2026-04
  6. June tools update
  7. The Tools Team
  8. Tools Architecture and Strategy Team
  9. RFC 8711
  10. IETF Administrative Strategic Plan 2020
  11. Datatracker issue #9204