Slack Guidelines

Slack serves as the main communication platform for the Kubernetes community outside of the mailing lists. It’s important that conversations stay on topic in each channel, and that everyone abides by the Code of Conduct . There are over 200,000 members who should all expect to have a positive experience. You are a part of building and keeping a positive community.

Chat is searchable and public. It’s best not to make comments that you would not say on a video recording or in another public space. Please be courteous to others.

Code of Conduct

Kubernetes adheres to the Kubernetes Code of Conduct throughout the project, and includes all communication mediums.

Joining Slack

To join the Kubernetes Slack, you must use the community inviter . No other method of joining Kubernetes Slack will work.

Please do not send in-Slack Invitations to your coworkers or friends. They will not be able to join our Slack that way. Instead, direct them to the community inviter .

Admins

The centralized list of administrators has contact information.

Slack Admins will have listed that they are a Slack admin in their Slack profile, along with their specific timezone.

To connect: please reach out in the #slack-admins channel, mention an admin directly in the #slack-admins channel when you have a question, or DM (direct message) one privately.

Workspace Channel History

The Kubernetes Slack Workspace is archived and made available when the administrators have time. There is no explicit interval.

Slack Archive Download

General Slack Usage Guidelines

Activities We Encourage

Slack is the key communications platform for our community. As such, all of the following behaviors and activities are allowed and encouraged on our Slack:

• Following the Code of Conduct
• Generally adhering to the stated channel topics, and putting discussions in the appropriate channels. For example, a security question should be discussed in #kubernetes-security, #sig-auth, or #sig-security, but a question about kubectl commands isn’t appropriate there.
• Occasional social chatting, which fosters a sense of community. Just don’t let it overwhelm the on-topic content of the channel, and be wary of discussing topics that might be very upsetting to some community members (e.g. international conflict).
• Offering help and assistance to other users looking for answers.
• Posting reminders about community meetings and activities which are appropriate to the channel (e.g. upcoming SIG meetings).

Prohibited Activities

Doing any of the below is prohibited. Breaking these rules can result in warnings, deletion of posts, restrictions on posting, temporary or permanent deactivation of user accounts, and even restrictions on entire organizations. We rely on our community to report prohibited behavior to the Slack admins; if you see any of the below, please use the Message Reporter .

• Violations of the Code of Conduct
• Posting Spam: you may not post commercial, promotional messages anywhere in Kubernetes, whether in public channels or direct messages, except for very specific types of messages in specific channels were it is allowed.
• No Automated Access: Kubernetes Slack is for contributors to connect with other contributors. Connecting any automated program or service to Kubernetes Slack without explicit approval by the Slack Administrators or K8s-Infra is strictly prohibited. This includes, but is not limited to, app plugins, AI agents, chat bots, social media management platforms, backup tools, and screen scrapers.
• Unsolicited Direct Messages: Do not send a direct message (DM) to any user who has not invited it, and that you are not approaching in their official role in the Kubernetes project. In general, ask questions in public channels.
• Company Business: Proprietary conversations should occur in your company Slack and/or communication platforms.
• Self-Promotion: users posting about their blogs, podcasts, LinkedIn profiles, non-Kubernetes projects, or other personal content in order to drive traffic is considered spam and prohibited.

Content Restricted to Specific Channels

Several types of posts are restricted to specific Slack channels, and posting this content elsewhere is a violation that can result in a warning, restrictions on posting, or deactivation of your account.

• Surveys: surveys, focus groups, free trials, and similar calls for participation may only be posted on the #surveys channel. However, an official Kubernetes community survey can be posted anywhere.
• Jobs and Resumes belong on the #kubernetes-careers channel and should not be posted elsewhere.
• Events may only be posted to channels where that specific event is applicable, or the #events channel. In general, this should be only nonprofit community events.

Specific Channel Rules

Some channels have specific rules or guidelines. If they do, they will be listed in the purpose or pinned docs of that channel. A few channels worth mentioning include:

• #events - announcements around any Kubernetes ecosystem related events.
• #kubernetes-new-contributors - Questions and discourse around getting started contributing to Kubernetes.
• kubernetes-org-members - Discussion by and for organization members and established contributors.
• #surveys - Cloud native community wide surveys. Posts must be ecosystem related.
• #kubernetes-careers - Job openings for positions working with/on/around Kubernetes. These must be postings for specific jobs, not “cattle calls” for general tech hiring. To maintain community safety and combat fraudulent listings, all posts now require a structured form submission and pass through a moderated triage queue before becoming visible to the community.
  • Form Submission: Complete either the Job Posting Form or the Resume Form inside Slack based on your intent.
  • Triage Queue: Submissions do not appear instantly. They are routed to a private administrative review space.
  • Manual Vetting: Channel moderators review submissions to screen out malicious links, fake profiles, and scams.
  • Need More Information: If a job listing is missing mandatory fields, additional information will be needed for approval.

Job opening submissions require a direct corporate portal, official ATS, or accessible portfolio URL; a matching corporate domain email (public domains such as @gmail.com will be rejected); explicit geographic constraints for Hybrid or On-site roles and direct, unshortened resume links. Third-party URL shorteners are not permitted.

Job posting will be rejected for missing, broken, or permission-locked links; mismatched business email domains; anonymous or unverified recruitment agency postings; or any content related to cryptocurrency, investment schemes, or unrelated topics. If your post does not appear within 48 hours reach out in #slack-admins for a status update.

Resume Submission: Provide your full name, professional contact information, and a direct resume link (Google Drive, GitHub, or personal website), along with a brief description of your background. Direct, unshortened links only; URL shorteners will result in immediate rejection. Resume submissions are reviewed for basic safety and legitimacy, following the same community standards as job postings. For full moderation criteria, see the Job Posting Vetting Policy .

Reporting a Problem

The Kubernetes Slack has an integrated tool for reporting issues. It may be accessed by clicking on “More actions”, the “…” to the right of a message, selecting “connect to apps”, and selecting Report message.

This will open a new dialog prompt where you may describe the problem. When done, it will send the reported message and your comments to BOTH the Slack admins and Code of Conduct Committee (CoCC) . You may report anonymously.

A Slack admin or CoCC member will work to resolve the issue or reach out for more information. Due to report volume, if the Slack admins do not require additional information they may take action without reporting back to you.

If the issue is complicated or still unresolved after some time, join the #slack-admins channel and alert the admins to the current issue. Many Slack admins watch the channel and should respond to you shortly, although they respond to the Message Reporter more quickly.

As a last resort, or if the issue is private, contact one of the admins in the closest timezone via DM directly and describe the situation. If the issue can be documented, please take a screenshot to include in your message.

What if you have a problem with an admin?

Send a DM to another listed admin and describe the situation. If it’s a code of conduct issue, please send an email to conduct@kubernetes.io and describe the situation.

Channel Management

This section, and the sections below it, are intended for SIG Leads, channel owners, and Slack admins. If you are new to Kubernetes and Kubernetes Slack, you can stop reading here.

Should you have a channel on the Kubernetes Slack?

The primary purpose of the Kubernetes slack is for the coordination of the Kubernetes project. However it is useful for developers and users to have a strong ecosystem of channels for related things. Here are some guidelines for determining if you should request a channel:

• The channel MUST be Kubernetes related in some way.
  • Related cloud native projects might be more appropriate on the CNCF Slack .
• If requesting a project channel, the project MUST be open source.
  • Open Source a project BEFORE requesting a channel. We cannot accommodate every organization’s open sourcing launch plans.
  • The purpose of Slack is to organize an existing community, not seed new ones.
  • Moderators look at contributor activity, adoption and community consensus around a project, otherwise Slack becomes a vehicle for promotion instead of promulgation.
  • Establishment and maintenance of a Slack channel should be an inflection point in a project’s adoption.
  • Requesting a channel means maintaining it on behalf of the project filing the issue. You will be expected to participate and foster a healthy discourse.
  • External projects (ones not owned by a Kubernetes SIG) may have a maximum of two channels, usually #project or #project-users, and #project-dev.
  • A second channel for a specific project will not be approved until the first channel demonstrates significant traffic.
• Channels around commercial services built on OSS projects are allowed.
  • Users love the value of being able to collaborate around various services.
  • Keep it classy, on the Kubernetes Slack we’re all on the same team.
• The channel MUST be public.
  • In order to ensure all channels adhere to our Code of Conduct, we heavily restrict private channels.
  • If you need private discussion areas for security-sensitive topics, a project-specific Slack or the CNCF Slack may be a better fit.
• Ask in #slack-admins or file an issue if you’re unsure. We’re happy to discuss it with you.

Private Channels

We offer private channels on the Kubernetes Slack extremely sparingly. The only private channels we currently support involve community-owned software security or community moderation in some way. Unless supported by a Kubernetes SIG or the Steering Committee, requests for a private channel will be treated with skepticism.

Most private channels will be required to include a member of the Slack Admins team.

Requesting a Channel

Channels and User Groups are managed by Tempelis , a tool that enables external management of Slack.

To add a channel, open a Pull Request (PR) updating the slack-config .

• Add the channel to ‘channels.yaml’ following the Channel Documentation
  • Channel names must be 21 characters or less in length, limited by Slack design.
  • Channels must not share the same name with a Slack user or user group.
  • Typical channel naming conventions follow:
    • #kubernetes-foo
    • #sig-foo
    • #meetup-foo
    • #location-user
    • #projectname
• In the PR comments, include some details regarding the purpose of the Channel.
  • Channels should be dedicated to SIGs or WGs , sub-projects, community topics, or related Kubernetes programs/projects.
  • Linking to resources such as the PR adding the subproject will speed in the validation and processing of the channel creation request.
  • Channels are NOT
    • Company specific; cloud providers are ok with product names as the channel. Discourse will be about Kubernetes-related topics and not proprietary information of the provider.
    • Private channels with the exception of: code of conduct matters, mentoring, security/vulnerabilities, github management, or steering committee.
  • Special accommodations will be made where necessary.

After you submit your request the Slack Admins will review and follow-up with any questions in the PR itself. There are two approvals needed. /lgtm and /approve. Once one moderator give the /lgtm, a hold will be placed on the PR using /hold. This hold will remain in place until one or more moderators reviews and add the /approve command as well as /hold cancel, which will remove the hold on the PR. Once it is signed off and merged, the channel will be created.

For further information, see the Slack Config Documentation .

Delegating Channel Ownership

Channel management can be delegated to other groups, enabling SIG leads or other members to govern certain sets of channels. This bypasses the need for a Slack Admins to sign-off on all requests and passes the responsibility to the most relevant group.

To delegate channel ownership - Open a Pull Request (PR) updating the slack-config .

• Create a sub-directory under the slack-config for your sig or group.
• Update restrictions.yaml with an entry targeting yaml config files in the sub-directory you created along with one or more regular expressions that match the channel names that should be delegated.
  • Example Restrictions Entry:

    restrictions:
    - path: "sig-foo/*.yaml"          # path to channel config
      channels:
      - "^kubernetes-foo-[a-z]{1,3}$" # channel regexp - example match: kubernetes-foo-bar
      - "^foo-[a-zA-Z]+$"             # channel regexp - example match: foo-awesomechannel
    

• Create an OWNERS file in the sub-directory adding the appropriate reviewers and approvers for the desired channels.
• In the directory create one or more channel configs following the Channel Documentation
  • Example Channel Config:

    channels:
    - name: kubernetes-foo-bar # regexp: "^kubernetes-foo-[a-z]{1,3}$"
    - name: foo-users          # regexp: "^foo-[a-zA-Z]+$"
    - name: foo-dev            # regexp: "^foo-[a-zA-Z]+$"
    

After you submit your PR and the Slack Admins sign off on the update, it will be merged and the group will be able to fully self-manage their own channels.

For further information, see the Slack Config Documentation .

Requesting a User Group

Channels and User Groups are managed by Tempelis , a tool that enables external management of Slack. In this case, we are talking about teams defined within Slack, which it calls “User Groups”, and not the former Kubernetes governance concept called “User Groups”.

To add a User Group, open a Pull Request (PR) updating the slack-config .

• Add the users to users.yaml. NOTE: This must be a mapping of their GitHub ID to their Slack Member ID.
• To get a person’s Slack Member ID, view their profile. Then click on the “…” and select Copy member ID. It will be a 9 character string of uppercase letters and numbers (example: U1H63D8SZ).
• Update usergroups.yaml Follow the guidelines for creating a User Group in the Slack Config User Group Documentation .
• In the PR comments, include details on the User Group and /cc the members you are adding so that they may sign off and accept being added to the group.

After you submit your request, the Slack Admins will review and follow-up with any questions in the PR itself. Once it is signed off by the members being added and the Slack Admins, it will be merged, and the User Group will be created.

For further information, see the Slack Config Documentation .

Requesting a Bot, Token, or Webhook

READ BEFORE SUBMITTING A REQUEST

Bots, tokens, and webhooks are reviewed on a case-by-case basis with most requests being rejected due to security, privacy, and usability concerns. Bots and the like tend to make a lot of noise in channels. The Kubernetes Slack instance has over 145,000 members and it is the role of the Slack admins to ensure everyone has a great experience.

Typically approved requests include: GitHub, CNCF requests, or other tools/platforms used to aid in the management of Slack itself.

• Create a GitHub Issue using the Slack Request template.
• In the description, describe the request, its intended purpose and benefit to the community. Supplying links to supporting content such as a document outlining what OAuth scopes that are requested and why are STRONGLY ENCOURAGED.

After you submit your request, the Slack admins will review and follow-up with any questions in the issue. If consensus can be reached among the admins, the request will be approved and follow-up communication on implementation will be discussed in Slack itself.