Résumé

  • Les règles publiées de Kubernetes permettent l’admission de certains canaux de projets externes, décrivent la revue par les administrateurs Slack et prévoient une délégation bornée de gestion.
  • L’issue Steering #307 rend publique une inquiétude sur la modération, les archives et une migration éventuelle, sans constituer pour autant une politique modifiée ni une garantie de service.
  • Un relevé d’état du canal devrait distinguer la règle applicable, le responsable, l’approbation, la délégation, l’archive et toute décision formelle de continuité.

Être hébergé ne signifie pas être garanti

La première erreur vient du verbe « accueillir ». Kubernetes Slack peut accueillir un projet voisin et lui permettre de réunir ses utilisateurs. Cela n’implique pas que le projet Kubernetes se soit engagé à conserver indéfiniment la conversation, à exporter son historique, à financer un changement de fournisseur ou à reconstruire le canal après une interruption. L’hébergement est une décision d’admission; la continuité est une suite de responsabilités qui doit être nommée séparément.

Les Slack Guidelines actuelles donnent à l’admission une forme précise. Leur objet principal est la coordination de Kubernetes, tout en reconnaissant l’utilité de canaux liés à son écosystème. Un canal de projet demandé doit concerner Kubernetes et le projet doit être open source. La personne qui le demande est censée le maintenir au nom du projet. Pour les projets extérieurs à un SIG, la règle prévoit normalement au plus deux canaux. La demande passe par une modification de slack-config, revue par les administrateurs; la page décrit /lgtm, /approve, puis la création après signature et fusion de la modification.

Ce parcours prouve quelque chose de réel : une configuration a été proposée, examinée et admise selon une règle. Il ne prouve ni la date du prochain archivage, ni l’existence d’une copie complète, ni le titulaire d’une obligation de migration. Les lecteurs doivent résister à la tentation de transformer une décision de porte d’entrée en assurance de sortie.

La délégation change la gestion locale, pas le niveau d’engagement

La documentation prévoit aussi que la gestion de certains canaux puisse être déléguée. Un groupe peut définir, par pull request, un répertoire, des restrictions de noms, un fichier OWNERS et la configuration des canaux qui lui sont attribués. Après l’accord des Slack Admins et la fusion, le groupe peut gérer lui-même ce périmètre.

Cette délégation n’est pas symbolique : elle distribue une capacité opérationnelle à l’endroit le plus proche du canal. Mais elle demeure une délégation de configuration circonscrite. Elle ne remet pas au groupe les conditions commerciales de la plateforme, la garde de l’espace entier, l’autorité de modifier la politique de communication de Kubernetes, ni l’obligation de faire survivre chaque historique à un changement de fournisseur. Une même personne peut être mainteneur de canal et participant à une discussion de politique; ces rôles ne fusionnent pas pour autant.

La distinction devient essentielle lorsqu’un incident ou une migration est évoqué. Le groupe délégué peut connaître les mainteneurs, mettre à jour sa configuration autorisée et expliquer le but de son canal. Il n’est pas nécessairement celui qui peut obtenir une exportation, définir l’ordre d’une migration générale, payer un remplacement ou déclarer qu’une archive est suffisante. Un système sain ne transfère pas ces risques par sous-entendu.

L’issue ouverte documente une lacune, non une règle nouvelle

L’issue Steering #307 est une source importante, mais de nature limitée. Elle part de la question de savoir si Kubernetes doit continuer à prendre en charge des projets tiers dans Slack. Elle rappelle les incertitudes rencontrées lorsque le statut du service Slack a changé en 2025 : responsabilité entre acteurs, conservation de l’information, migration possible, coût et soutenabilité. Les commentaires discutent de modération, de l’écart entre canaux officiels et tiers, de l’intérêt de conserver les éléments importants dans Git ou ailleurs, et de priorités possibles en cas de crise.

Ces échanges doivent guider une meilleure politique, non être présentés comme cette politique. L’un des commentaires rapporte une compréhension issue d’une conversation sur l’absence de modération de certains canaux tiers et une priorité différente lors d’une migration ou d’un désastre. Un autre demande qu’un texte soit clarifié et rédigé avant la clôture. En août, le fil demandait encore si ce projet de texte avait été produit. L’issue reste ouverte.

Il serait donc erroné d’écrire que Kubernetes a déjà adopté une règle générale de non-assistance aux canaux tiers, qu’un canal identifié sera supprimé, ou qu’une hiérarchie de migration a été officiellement décidée. Mais l’erreur inverse serait d’ignorer le problème exposé. Le dossier public montre précisément que les attentes de continuité ne sont pas encore reliées à un acte de politique lisible.

Une archive annoncée n’est pas un reçu de restauration

Les lignes directrices indiquent que l’espace Slack est archivé et rendu disponible lorsque les administrateurs en ont le temps, sans cadence explicite. Cette formulation mérite d’être prise au sérieux, et avec mesure. Elle décrit une pratique générale; elle n’atteste pas qu’un canal donné a été capturé, que son dernier export est complet, qu’il peut être relu demain ou qu’il serait transportable vers un autre service.

La continuité de l’information exige davantage qu’un lien vers une archive. Il faut savoir quelle politique s’appliquait, qui gérait le canal, ce qui a été conservé, quelle limite de confidentialité existe, qui déciderait d’une transition et quel avis serait donné. Sans ces éléments, un historique de chat peut être précieux sans devenir pour autant une archive de référence.

Rendre l’état intelligible sans promettre l’impossible

Un relevé d’état sobre pourrait commencer par l’identifiant stable du canal, sa classe — officiel, lié à un SIG, délégué ou externe — et la version de la règle d’admission. Il ferait apparaître le groupe demandeur ou mainteneur, la modification approuvée et la limite exacte de toute délégation. Il distinguerait ensuite la pratique d’archive publiée d’un engagement de continuité réellement adopté.

Le champ le plus important peut légitimement dire « aucune promesse de migration publiée ». Cette phrase vaut mieux qu’un silence que chacun interprète à sa convenance. Si une autorité compétente adopte ensuite une période de préavis, une exportation proposée, un responsable de transition ou une priorité de service, le relevé ajoute la date, le périmètre et le lien vers l’acte formel. Il n’a pas besoin de publier des rapports de modération, des coordonnées privées ou des conditions commerciales.

Le but n’est pas de créer un droit automatique à une infrastructure gratuite. Il est d’empêcher que l’admission, la gestion locale et la continuité soient confondues. Une communauté peut accepter des limites de service; elle ne devrait pas devoir deviner lesquelles.

Sources

  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