Summary

  • Kubernetes’ published Slack rules explain when a related external project may request a channel, how Slack-admin approval works, and how a group can receive scoped channel-management delegation.
  • The open Steering issue about third-party channels records real questions about moderation, archives and a future provider change, but it has not become an amended public continuity policy or a service promise for any channel.
  • A channel-state receipt should show the policy version, channel class, manager, approval, delegation, archive state and any formal continuity decision without inventing support obligations that the record does not contain.

A channel request answers a narrow question

A shared workspace makes its own category error tempting. Someone sees a channel in Kubernetes Slack and assumes that Kubernetes has taken responsibility for the channel’s future. The presence is visible, the name resembles a project affiliation, and the request may have been approved in a public pull request. Yet admission is a narrower administrative act: it says that a channel satisfies the conditions for being created in a shared communications space at that time.

The current Slack Guidelines make this distinction unusually concrete. Kubernetes Slack exists primarily to coordinate the Kubernetes project, but the guidelines also allow an ecosystem of related channels. A requested project channel must be Kubernetes related and open source. The page says that the person requesting it will be expected to maintain it for the project. An external project that is not owned by a Kubernetes SIG may normally have up to two channels. The request travels through configuration in slack-config; Slack Admins review the pull request, the documented review flow uses both /lgtm and /approve, and a signed-off, merged configuration creates the channel.

That is a meaningful record. It can show that a channel was admitted under a policy, that a request followed a route, and that designated reviewers accepted the configuration. It does not establish a retention period, a recovery point, an export format, a migration owner, a payment commitment or a priority tier if the workspace changes. The rule that allows a channel to begin is not automatically a rule that keeps it usable through every later contingency.

Delegation is scoped management, not custody of the platform

The same guidelines describe a second, different act: delegation of channel ownership. A SIG or another group can use a pull request to define a directory, restrictions for an allowed channel set, appropriate reviewers and approvers, and configuration for the relevant channels. After Slack Admin signoff and merge, that group can self-manage the channels within the stated scope.

This avoids an opposite mistake. A delegated group is not merely an audience inside the workspace; it receives an operational role over an identified set of channel configurations. But scope matters. Configuration authority for a set of channel names is not ownership of the workspace, control of Slack’s commercial terms, custody of every archive, or authority to rewrite Kubernetes communications policy. It also does not give the group a general mandate over an external project that happens to use one of the channels.

The distinction is practical in a disruption. A delegated group may be the right party to update a permitted channel configuration or identify its maintainers. It may not be the party that can obtain an export, fund a replacement platform, determine a workspace-wide migration sequence or promise that historic material will remain available. Those are separate decisions with separate evidence. Treating a configuration delegation as a continuity guarantee asks a local owner to carry a risk that the public record did not assign.

The open issue is evidence of concern, not the new rule

Steering issue #307 is valuable because it exposes the missing question without pretending to have settled it. The April issue asks whether Kubernetes should support third-party projects in its Slack workspace and points to uncertainty exposed during the 2025 change in Slack’s service circumstances: who was responsible for what, whether information could be preserved, how a move might work, and who would sustain or pay for the service. Its comments discuss moderation load, the different standing of official and third-party channels, the need to keep important material in more persistent systems, possible deletion, and migration priorities.

Those comments should neither be ignored nor promoted into law. They give readers evidence that experienced participants identified a continuity problem. One comment records a conversational understanding about no moderation for certain third-party channels and a different priority in a migration or disaster case. Another says the guidelines should be clarified and a draft produced before the issue is closed. In August, the public record still asks whether that draft was made. The issue is open.

That final state changes the permissible claim. The discussion cannot be reported as a completed revision to the Slack Guidelines. It cannot prove that every third-party channel has no support guarantee, that a named channel will be deleted, or that Kubernetes has adopted a migration tier. Conversely, the lack of an amended rule does not prove that no one would help in a real incident. It means that the public policy record has not specified the handoff that would let outsiders know who is responsible for which continuity action.

An archive mention is not an archive contract

Kubernetes’ public page also says that the workspace is archived and made available when administrators have time, with no explicit interval. This matters because it is a real public statement about historical material. It is not, however, an audit of a particular channel. The statement does not identify whether a channel’s history has been captured, the most recent successful capture, its completeness, its access terms, its exportability or the person who would restore it after a provider change.

An ordinary archive link can therefore support only an ordinary conclusion: the project describes an archival practice. It cannot be stretched into a recovery receipt. A community that treats chat as its only decision record may discover the difference too late, when a workspace policy changes, administrators rotate, or the discussion must be reconstructed for a dispute. The most important policy decisions should have an independent public home even when chat remains an efficient place to coordinate them.

Make the unfinished state inspectable

Kubernetes does not need to promise indefinite service in order to describe its policy honestly. A compact channel-state receipt would begin with the stable channel identifier, its class—official, SIG-linked, delegated or external—and the version of the admission rule used. It would identify the requesting or maintaining group, the approving configuration change and any delegated-management boundary. It would then state the archive posture that is actually documented: for example, best-effort workspace archive with no published interval, or a later formally adopted channel-specific rule.

Continuity deserves its own field rather than an optimistic blank. The state may be “no published migration commitment,” “notice-only,” “export offered,” “transition owner identified,” or another policy term that an authorised body has actually adopted. A change should add a dated record showing the decision venue, scope, effective time and link to the formal policy or configuration. It need not expose private moderation reports, personal contact information, vendor terms or confidential security work.

The receipt would not create a right to a free channel, a backup, or an indefinite archive. It would do something more modest and more reliable: keep admission, local management and continuity decisions from being quietly substituted for one another. That is the difference between a visible channel and an intelligible communications policy.

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