Revision of third-party slack channels projects

[aojea]

This is an spin-off from kubernetes/community#8924

So, there is a policy about slack channels in kubernetes org defined in https://www.kubernetes.dev/docs/comms/slack/#should-you-have-a-channel-on-the-kubernetes-slack

This policy allows to host third party projects on kubernetes slack, that is maintained by the slack-admins group

https://github.com/kubernetes/community/blob/main/communication/slack-config/README.md

Slack is not a free service, and back in 2025 the project faced a dramatic situation when the company decided to downgrade the special status , @joshberkus blogged about it https://kubernetes.io/blog/2025/06/16/changes-to-kubernetes-slack/

During that time of uncertainty some problems where very evident, it was unclear how to migrate everything and also not loosing information , who was responsible of what (CNCF or slack admins or ...) but it was clear that Kubernetes and CNCF slack were completely different things https://www.cncf.io/blog/2025/06/16/cncf-slack-workspace-changes-coming-on-friday-june-20/ and with different owners.

I think that to avoid any issue in the future, we should be more clear about our slack policies.

Do we want to support third party projects? there are already a number of third party projects using our slack and more are being added, so we can create an unfair situation.

However, are these projects aware of the risks? are slack admins and the project able to sustain this? what happens if we need to pay for the services? or migrate to another provider?

This is not a new situation, we already have similar issues with prow and other resources, so I think that from the project perspective we should discuss more in detail this topic.

/cc @mrbobbytables @kubernetes/steering-committee @mfahlandt

[BenTheElder]

However, are these projects aware of the risks? are slack admins and the project able to sustain this? what happens if we need to pay for the services? or migrate to another provider?

This is my biggest concern. It's why we have https://registry.k8s.io/#stability and have pretty aggressively communicated this.

Even if expectations are unwritten, they exist and depending on the situation the project can suffer blowback when we can't continue supporting.

That said, I'm not sure that's the biggest problem here ... what about e.g. the moderation load? Are we doing OK there?

[jberkus]

However, are these projects aware of the risks? are slack admins and the project able to sustain this? what happens if we need to pay for the services? or migrate to another provider?

I don't think we've been particularly clear about this. I think that a revision to the Slack guidelines, accompanied by a comms broadcast, would make sense.

BTW, the expectations I would communicate is:

Kubernetes Slack is a "best-effort" service. The project and the Slack admins make no guarantees about the continued availability or utility of any specific Slack channels. In the event of any Slack-wide issue, our Slack admins will assist only official Kubernetes project channels, and other channels will need to find their own solutions.

Aside from concerns around unexpected events, someday we might decide to shut down a whole set of 3rd Party channels by policy.

[jberkus]

That said, I'm not sure that's the biggest problem here ... what about e.g. the moderation load? Are we doing OK there?

While it's always worth discussing moderation staffing, the amount of activity on the 3rd-Party channels is such a tiny fraction of the total activity that it doesn't create any noticeable increase in load.

[mfahlandt]

Just thinking out loud here. As far as I am aware, we are now in much better shape regarding Slack than we have ever been from the point of view of being rug pulled. Maybe @mrbobbytables can chime in here from CNCF side.

For the whole moderation topic. The CNCF Slack gives every user the right to create channels. I don't want to have this necessarily for k8s, but perhaps from a policy / moderation standpoint we can argue. Active moderation is only happening in official channels. Code of Conduct violations still need to be reported to CoCC and if something really goes south we take the right to remove the channel without further notice.

I would not want to leave projects/channels hanging. Especially as we also have a lot of CNCF projects in our Slack as their main channels of communication.

And as hard as it sounds. We should treat Slack not as a source of truth. If it is important, it should be in Git / Github or in Google Drive or some other persistent place.

[jberkus]

@mfahlandt speaking as a Slack Admin, I will make zero effort to rescue a 3rd-party channel that's in trouble. Like, if a non-Kubernetes channel becomes a source of regular complaints by multiple users, I'm going to propose to the other admins that the solution is to delete it (and notify the CoCC, of course). If we have to guarantee a level of support for all channels we offer, then we're going to need to be a lot more restrictive about granting channels in the first place (and will want to delete many of the 3rd party channels that already exist).

[mfahlandt]

@jberkus and I had a chat during the ContribEx Biweekly Call on Wednesday, the 15th of April.

The understanding that we reached is that there will be no moderation in those channels. If there is an increased number of violations, third-party channels will be deleted without further notice.
In the event of a migration/disaster case, Kubernetes-owned channels have the highest priority, and there is no guarantee of support for moving or help with backing upthird-party channels.

We still think it is beneficial to offer third-party channels and to have adjacent topics to Kubernetes in our Slack, as the project also benefits from this. (Intake of new interested community members, support for adjacent projects, etc.)

[aojea]

Perfect, should we close or do you prefer to update first https://www.kubernetes.dev/docs/comms/slack/#should-you-have-a-channel-on-the-kubernetes-slack

[mfahlandt]

I think we should clarify and then close this here :) I will draft something next week