Zusammenfassung

  • Die Slack-Regeln von Kubernetes beschreiben Antrag, Prüfung und Erstellung zugehöriger externer Projektkanäle sowie eine begrenzte Delegation der Kanalverwaltung.
  • Steering-Issue #307 hält Fragen zu Moderation, Archiv und Plattformwechsel fest, bleibt aber offen und ist weder eine geänderte Regel noch eine Zusage für einen bestimmten Kanal.
  • Ein Zustandsnachweis sollte Aufnahme, lokale Verwaltung, Delegation, Archivlage und jede formell beschlossene Kontinuitätsentscheidung getrennt ausweisen.

Eine Aufnahmeentscheidung beantwortet nur die Aufnahmefrage

Die Slack Guidelines nennen Kubernetes-Projektkoordination als Hauptzweck des Arbeitsbereichs und erlauben zugleich verwandte Kanäle. Ein beantragter Projektkanal muss Kubernetes-bezogen und das Projekt Open Source sein; Antragsteller sollen ihn für das Projekt pflegen. Externe Projekte außerhalb eines SIG haben normalerweise höchstens zwei Kanäle. Der Antrag verändert slack-config, Slack Admins prüfen ihn, und die dokumentierten Schritte /lgtm, /approve und Merge führen zur Erstellung.

Das ist ein überprüfbarer Vorgang. Er zeigt, dass eine Konfiguration unter einer bestimmten Regel angenommen wurde. Er zeigt nicht, wie oft ein Verlauf exportiert wird, ob ein Export vollständig oder wiederherstellbar ist, wer bei einem Anbieterwechsel informiert, wer eine Migration priorisiert oder wer sie bezahlt. Aufnahme und Fortbestand sind verschiedene Entscheidungen.

Delegierte Verwaltung bleibt begrenzt

Für eine Kanalgruppe kann die Verwaltung an ein anderes Team delegiert werden. Dieses legt per Pull Request ein Verzeichnis, Namensbeschränkungen, ein OWNERS-File und die betreffende Konfiguration an. Nach Signoff und Merge kann es die zugewiesenen Kanäle selbst verwalten.

Damit erhält das Team einen echten lokalen Handlungsraum, aber keine Verfügungsgewalt über den gesamten Workspace, Slack-Verträge, globale Kommunikationspolitik, alle Archive oder die Kontinuität eines Drittprojekts. Es kann in seinem Bereich konfigurieren und Maintainer kennen. Daraus folgt weder eine Befugnis noch eine Pflicht, einen Chatverlauf zu retten oder eine Ersatzplattform bereitzustellen. Ein Titel wie „Owner“ ersetzt keine genaue Verantwortungsgrenze.

Ein offenes Issue ist kein beschlossener Standard

Issue #307 beschreibt, was im vorhandenen Regelwerk fehlt. Es verweist auf Unsicherheit während der veränderten Slack-Situation 2025: Wie Informationen ohne Verlust verlagert werden könnten, wer wofür zuständig ist, ob Kanäle tragbar bleiben und was bei Kosten oder einem Wechsel des Anbieters geschehen würde. Kommentare sprechen über Moderation, den Unterschied offizieller und externer Kanäle, dauerhafte Quellen wie Git oder GitHub und mögliche Prioritäten bei Migration oder Ausfall.

Solche Beiträge sind wertvolle Hinweise, aber keine Normsetzung. Ein Kommentar fasst ein Gesprächsverständnis zu Moderation und Priorität zusammen; andere fordern zuerst eine Klärung und einen Entwurf der Richtlinien. Im August wurde öffentlich noch gefragt, ob dieser Entwurf vorliegt. Das Issue ist offen. Es belegt deshalb weder eine allgemeine Nichtunterstützungsregel noch eine verbindliche Rettungsreihenfolge noch die Zukunft eines bestimmten Kanals. Ebenso beweist es nicht, dass im Ernstfall niemand helfen würde.

Archivpraxis ist kein Wiederherstellungsbeleg

Die Guidelines sagen, der Workspace werde archiviert und verfügbar gemacht, wenn Administratoren Zeit haben; ein fester Rhythmus fehlt. Das ist eine Aussage über Praxis, nicht über die letzte vollständige Erfassung eines bestimmten Kanals, dessen Portabilität oder einen Wiederanlauf nach Plattformwechsel. Wichtige Entscheidungen sollten daher zusätzlich in dauerhaften, überprüfbaren Quellen liegen.

Einen ehrlichen Zustandsnachweis führen

Der vorgeschlagene Nachweis nennt Kanal-ID, Klasse — offiziell, SIG-bezogen, delegiert oder extern —, Version der Aufnahmeregel, antragstellende oder pflegende Gruppe, genehmigte Konfiguration und Delegationsgrenze. Danach folgt der tatsächlich dokumentierte Archiv- und Kontinuitätszustand. „Keine veröffentlichte Migrationszusage“ ist eine brauchbare Aussage, keine Unterstellung.

Kommt später eine autorisierte Entscheidung über Vorankündigung, Export, Übergabeverantwortung oder Serviceklasse hinzu, wird sie mit Datum, Umfang und Quelle angefügt. So entsteht kein Anspruch auf kostenlose Dauerleistung. Es wird nur verhindert, dass eine frühere Kanalaufnahme nachträglich als Kontinuitätsvertrag ausgegeben wird.

Quellen

  1. Kubernetes Slack Guidelines
  2. Kubernetes Steering issue #307
  3. Kubernetes Steering Committee Charter
  4. Kubernetes Community Governance
  5. Lu Heng, The Registry Continuity Fallacy
  6. Lu Heng, The Multi-Stakeholder Mirage