Кратко

  • Публичные правила Kubernetes описывают запрос и одобрение связанных внешних каналов, а также ограниченное делегирование их управления.
  • Issue Steering #307 фиксирует вопросы о модерации, архиве и миграции, но остаётся открытым и не является новой опубликованной политикой или гарантией сервиса.
  • Запись состояния канала должна раздельно показывать допуск, локального управляющего, делегирование, архив и любое формально принятое решение о непрерывности.

Допуск в рабочее пространство — не обещание выхода из него

Slack Guidelines Kubernetes говорят прежде всего о том, когда канал может быть создан. Основная цель Slack — координация проекта Kubernetes, хотя допускаются и каналы, связанные с его экосистемой. Запрашивающий проект должен быть связан с Kubernetes и быть open source; от заявителя ожидается поддержка канала от имени проекта. Внешнему проекту вне SIG обычно разрешены не более двух каналов. Заявка проходит через изменение slack-config, проверку Slack Admins, /lgtm, /approve и merge, создающий канал.

Это создаёт проверяемый след допуска. Он не устанавливает период архивации, полноту экспорта, владельца уведомления при смене поставщика, порядок миграции или обязанность финансировать замену. Разрешение на вход не отвечает на вопрос, кто и как сохранит функцию позже.

Делегирование не передаёт ответственность за всю платформу

Правила позволяют другой группе управлять определённым набором каналов: через pull request она добавляет каталог, ограничения имён, OWNERS и конфигурацию. После signoff и merge группа получает возможность самостоятельно управлять своим ограниченным набором.

Это реальная локальная роль, но не владение всем workspace, не контроль условий Slack, не право менять общую политику Kubernetes, не хранение всех архивов и не обязанность переносить историю стороннего проекта. Делегированная группа может знать сопровождающих и менять разрешённую конфигурацию. Нельзя из этого вывести, что она обязана или вправе гарантировать экспорт, восстановление либо миграцию.

Открытая дискуссия не заменяет принятого правила

Issue #307 показывает пробел. В нём вспоминается неясность, возникшая при изменении условий Slack в 2025 году: как перемещать данные без потерь, кто отвечает за разные части, что будет при платной услуге или смене поставщика. Комментарии обсуждают модерацию, различие официальных и сторонних каналов, необходимость хранить важный материал в Git, GitHub или ином долговечном месте, а также возможные приоритеты при аварии.

Это свидетельство обсуждения, а не его завершения. В комментариях есть предложения и пересказ разговорного понимания о модерации и приоритете. Есть и требование сначала уточнить правила и подготовить текст; в августе публично спрашивали, появился ли черновик. Issue остаётся open. Поэтому источники не подтверждают всеобщее правило об отсутствии помощи, официальную очередь спасения или судьбу конкретного канала. Они также не подтверждают, что помощь невозможна в настоящем инциденте.

Упоминание архива не доказывает восстановимость

Страница говорит, что workspace архивируется и становится доступным, когда у администраторов есть время, без заданного интервала. Это описание практики, но не подтверждение последней полной копии определённого канала, её переносимости или владельца восстановления. Значимые решения должны иметь и независимый долговечный источник, а не жить только в чате.

Сделать видимым и отсутствие обязательства

Небольшая запись могла бы содержать стабильный идентификатор, класс канала — официальный, 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