要約

  • Kubernetesの公開Slackガイドは、外部のオープンソース・プロジェクトがチャンネルを求める条件、管理者の承認、限定されたチャンネル管理の委任を定めている。
  • Steering issue #307はアーカイブや移行への懸念を公開しているが、開いたままであり、改定済みの方針や個別チャンネルへのサービス保証ではない。
  • チャンネルの状態記録は、承認、管理者、委任、アーカイブ状況、正式に採用された継続性判断を別々に表示すべきである。

受入れの判断は、出口の設計ではない

Kubernetes Slackのガイドは、まず何を受け入れるかを扱う。主目的はKubernetesプロジェクトの調整であるが、関連するエコシステムのチャンネルも認める。プロジェクト用チャンネルを求めるなら、そのプロジェクトはKubernetesに関係し、オープンソースでなければならない。申請者は当該プロジェクトのためにチャンネルを維持することを期待される。SIGが所有しない外部プロジェクトは通常二つまでのチャンネルに限られる。slack-configへのpull requestをSlack Adminsが確認し、/lgtm と /approve がそろってマージされればチャンネルが作られる。

この手続は単なる儀礼ではない。どの規則の下で設定が受け入れられたかを示す。しかし、保存間隔、完全なエクスポート、移行時の連絡担当、代替サービスの費用、ワークスペース変更時の優先順位はそこから出てこない。入口の承認を、将来の出口まで保証する文書として扱えば、証拠のない責任が生まれる。

管理の委任には境界がある

ガイドには、チャンネル管理を別のグループへ委ねる方法もある。グループは、対象名を制限する設定、ディレクトリ、OWNERS、チャンネル設定をpull requestで追加する。Slack Adminsの承認とマージの後、その範囲内のチャンネルを自ら管理できる。

ここで委ねられるのは、指定範囲の設定管理である。ワークスペース全体の所有、Slackの契約条件、全履歴の保管、Kubernetesの通信方針を変える権限、第三者プロジェクトへの移行約束ではない。地域的な管理権限と、プラットフォームの継続責任は異なる面にある。両方を同じ「owner」という語で呼ぶと、誰が何を引き受けたかが見えなくなる。

issueの会話は、正式な改定ではない

Steeringの#307は、この差を考えるための重要な公開資料である。2025年にSlackサービスをめぐる不確実性が生じた際、情報を失わずに移せるのか、Kubernetes・CNCF・管理者の責任はどこで分かれるのか、費用や別の提供者への移行を誰が支えるのかが明確でなかったと問題提起している。コメントではモデレーション負荷、公式チャンネルと第三者チャンネルの違い、重要な情報をGitやGitHubなどの持続的な場所に置く必要、災害時の優先順位が議論された。

その議論は無価値ではないが、規則でもない。第三者チャンネルのモデレーションや移行時の優先順位について会話上の理解を記すコメントがある一方、ガイドラインを明確化して草案を作ってから閉じるべきだというコメントもある。八月にも草案の有無が問われ、issueはopenのままである。

ゆえに、Kubernetesがすでに全第三者チャンネルへの支援を否定した、あるチャンネルを削除する、または公式の移行順位を決めたとは言えない。同時に、誰かが実際の障害時に助けると断言することもできない。公開記録が示すのは、期待と正式な継続性義務の間にまだ結ばれていない接続だけである。

アーカイブの案内は、復元の受領書ではない

ガイドは、管理者に時間があるときワークスペースをアーカイブして利用可能にすると述べ、明確な間隔は示さない。これは実践の説明であって、個別チャンネルの履歴がいつ完全に取得され、将来どこで読め、別のサービスへ移せるかの証明ではない。

重要な決定をチャットだけに残すことは、便利さを記録の強さと取り違える。必要なのは会話をすべて公開することではなく、重要な判断が別の持続的な記録にあり、アーカイブについて分かっていることと分からないことが明示されることである。

未確定の状態を記録する

提案する記録は、チャンネルの安定した識別子、公式・SIG関連・委任・外部という区分、適用された承認規則の版、申請または維持グループ、承認済み設定、委任の範囲を示す。その後に、実際に公表されたアーカイブと継続性の状態を書く。「公表された移行約束なし」は有効な状態であり、空欄よりも有用である。

後に権限ある主体が通知期間、エクスポート、移行責任者、支援水準を採用したなら、日付、範囲、決定文書へのリンクを追加すればよい。これは無料サービスへの権利を作らない。承認、局所管理、継続性を、後から一つの約束だったかのように語ることを防ぐ。

出典

  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