Kubernetes Contributors – Communication Platform Guidelines and Policies

Docs: Calendar and Meeting Guidelines

Mon, 01 Jan 0001 00:00:00 +0000

Calendar Guidelines

Project meetings are a life line of the Kubernetes project. Consistent calendaring is a challenge with many different clients, corporate policies, time zones and various iterations of Daylight Savings Time. This guide should help you navigate some of the common pitfalls and provide some tips & best practices.

Please feel free to PR in your favorite tips and tricks that may help others.

Calendar Guidelines

Establishing a New Meeting

“I’m a chair for a SIG or WG and need to set up a meeting.”

This procedure will create a calendar that allows for you and all your SIG/WG Chairs or Tech Leads to edit and manage the meetings.

NOTE: As of March 2019, this is the current best practice. However with the addition of gsuite, this practice may change soon.

Use a poll service such as doodle that will help you get a good pulse on your community and when they can meet.
Create a new shared calendar titled “[SIG|WG] Foo Shared Calendar” from a gmail/google account that will not have problems sharing or posting information publicly. This may mean using a personal gmail account if your corporate policies restrict sharing. See Testing Permissions to validate you can share your calendar.

Creating a shared calendar is essential. If you change jobs, email addresses, or take a break from the project it allows for a smooth transfer of ownership.

Configure access permissions and sharing:

Make all event details publicly accessible.
Share it with full rights (“make changes and manage sharing”) to your SIG/WG lead mailing list and contributors@kubernetes.io.
Let your other chairs and leads know they can accidentally delete a calendar while trying to delete it from theirs.
Share with view permissions only (“see all event details”) to your SIG/WG mailing list.

Once you have a time cadence settled from your members, create a calendar invite with the shared calendar as the owner. Configure it with the following settings:

Name it “[SIG|WG] Foo [Time Cadence ex: Biweekly] Meetings”.
Set sharing to public. NOTE: most gmail accounts will have a “default visibility” setting enabled. Default visibility is usually “private” and will need to be set to “public”.
In the calendar invite body - include your meeting notes, zoom information, and any other pertinent information that you want your group to know.
Invite calendar@kubernetes.io so the event will appear in https://www.kubernetes.dev/resources/calendar/

Testing Permissions

Make sure your work account doesn’t have restrictions for public viewing of calendar invites you create. If you are unsure, test this with other contributors before sending it to mailing lists. This is applicable for both the calendar entry itself and the shared calendar if you are the chair creating it.

Transferring Ownership

If a chair is offboarding, ensure that shared calendar permissions are configured. Once the calendar has been migrated, send out a new invite to ensure there are no possible ghost-entries in member’s calendars.

Tips

Viewing Kubernetes Project Calendars

“I’m a contributor and want to see one of/all of the SIG calendar(s).”

Public Kubernetes Events can be seen on the Public Community Calendar.

All of the SIGs and WGs have meeting agendas with detailed information at the top. You can get this information from the SIG/WG list. Join their mailing list for the most up to date calendar invites. Chairs will always invite the entire mailing list to their events.

Adding Events to Your own Calendar

Don’t copy calendars if you can help it. Copying the calendar onto your calendar will prevent you from getting updates like a canceled meeting. Join the main contributor mailing list and any SIG/WG list that is of interest.

Accept the invite from the sender and you’ll have the updates.

Calendar Event Template

In case you are creating a calendar event and wondering what to include in it, here is a recommended template.

Title

[SIG-<name>] <meeting title>
or
[WG-<name>] <meeting title>

Description

<One line intro about the SIG/ WG. Can include github links>
Time: <Weekly/ biweekly/... or is the meeting for a fixed time and till when?>
Meeting notes & agenda: <Hyperlink to the meeting notes doc>
Zoom link: <Zoom invite link. Preferably include app client link, web client link, and dial in information page link>
Additional info: <Any extra info/ links can be provided here>
Livestream link: <optional>
YouTube playlist: <optional>
Google group: <optional>

Example

SIG-Contribex: Weekly Contributor Comms Meeting

https://github.com/kubernetes/community/tree/master/communication/contributor-comms

Time: Weekly on Friday from 8-9am PT

Meeting Notes & Agenda: https://docs.google.com/document/d/1IlHAJ131akGhI5ffF4OoVW0PrsVY4C0BB8l-UyQaQVo/edit

Zoom link:

       App: https://zoom.us/j/XXXXXXXXX

       Web Client: https://zoom.us/wc/join/XXXXXXXXX

       Dial in numbers: https://zoom.us/u/bacaZSMhA

Troubleshooting

Permissions Impacted After Changing Positions or Role

“I’m a chair and the person that created the meeting is either no longer with the project or no longer at an employer that holds the invite”

If the calendar was created as a shared calendar with edit rights granted to other chairs and leads they should be able to edit the invite and migrate ownership without issue. If you do not have permissions, check first by sending an email to contributors@kubernetes.io. Permissions may have been granted that team and they will be able to facilitate the change in ownership.

If there is no shared calendar and still one owner, ask the person to transfer it to a shared calendar or you’ll need to create a new one. In these cases it often best to just create a new one to avoid any possible issues with the previous calendar. It doesn’t hurt to recreate a meeting invite every few months to refresh invites sent to the group.

Docs: Community Survey Requests

Mon, 01 Jan 0001 00:00:00 +0000

Requesting a Community Survey

Let us help you make your survey a success.

The Kubernetes project has access to the CNCF SurveyMonkey account for creating community surveys, and SIG-Contributor Experience includes people who can give advice on improving the quality of surveys, as well as promote them. As such, what follows is the process for requesting such a community survey, in order to maximize its reach and data quality.

What’s a Community Survey?

Any survey requested by a Kubernetes SIG, WG, Team, or other standing Kubernetes community group (hereafter “Group”) that targets some or all of the Kubernetes community and ecosystem is potentially a community survey. As some examples, this would include:

A survey by SIG-Cluster-Lifecycle on upgrade practices, targeted at Kubernetes users
A survey by SIG-ContribEx on contributor events, targeted at current contributors
A survey by the Release Engineering Team, targeted at vendors who repackage Kubernetes

Not included in community surveys are: surveys by specific vendors, surveys by other CNCF projects, surveys of target audiences outside the Kubernetes/CNCF community, or surveys that cannot be executed using SurveyMonkey and/or Google Docs.

If the survey you want to do is a community survey, then then next thing is to submit a request.

Survey Request Process

1. Determine Goals and Content of Survey

The first step needs to happen in your community Group. You need to determine:

Why you want to do a survey
Who you would like to answer it
What specific questions you want to ask

Ideally, answer those questions in that order; first decide what your goals are, next which audiences you’re targeting, and finally compose the individual questions.

Your survey will also need a preface which explains to the audience what the survey is for, who will get to see its raw results, and where compiled data from it will be published.

2. Request Survey Review

Put your draft survey questions in a Google Doc, HackMD page, PR against one of your Group repos, or other format that supports comments by reviewers. Then open an issue against the community repo using the Survey Request template.

Members of SIG-ContribEx will then offer feedback on improving your survey, in the following areas:

Are the questions and options clear and unambiguous?
Are there obvious missing options to some questions?
Is the preface clear and complete?
Does the survey comply with the Kubernetes CoC and privacy practices?

Once you feel like the survey is as good as it’s likely to be, we can publish it.

3. Request Survey Publication

By default, we use a SurveyMonkey account funded by the CNCF to publish surveys. This is because SurveyMonkey offers a fairly rich set of survey options, and more importantly is accessible in China. We can also publish surveys using the Kubernetes Google Drive account, if surveying Chinese developers or contributors is not a consideration. GDrive makes sharing the survey results easier.

In either case, it will take a few days for a ContribEx volunteer to copy the questions and options into the survey tool, and then it can be ready to announce on your schedule. Just comment on the issue giving your requested publication schedule, and mark it LGTM.

4. Contributor Communications Promotion (optional)

If you want your survey to reach a large number of contributors, developers, or users, then the Contributor Marketing subproject can help. Use the contributor comms issue template to request help from that group. They will ask you some questions about promoting the survey and assist you in getting the word out, via the Kubernetes social medial accounts, mailing lists, and blog, depending on the target audience and scope.

5. Collect Survey Results

Your survey can be open anywhere from a few days to a few months, depending on your needs. In addition to any efforts Contributor-Comms may be making on your behalf, during this period your group should make sure to remind folks several times that the survey is open.

On request (via the Github issue or Slack messages) ContribEx volunteers can supply intermediate information, such as the number of surveys completed or the current results data.

6. Publish Survey Results

When the survey is complete, the designated recipients for the raw data will receive a data dump in the form of a spreadsheet or CSV file, accompanied by copies of the simple graphs created by the survey system. As this data may contain personally identifying information, the recipients are required to be a small group who will treat the data with care.

Depending on the availability of some ContribEx members, you may also be able to get more advanced visualizations and/or data analysis assistance. This would be primarily correlating the answers to two or more questions, and providing graphs or charts for those correlations. Request this in your issue and we’ll follow-up to help figure out exactly what you need.

Tips and Notes Around Surveys

Please note that we are subject to the GDPR and other privacy regulations. As such, your survey will need to explain who will have access to the data and what it’s for, and you need to adhere to those restrictions. Among other things, this means that you can never share raw survey data on a public mailing list or or GitHub repo (summary data that contains no personal information should be fine).

Some additional tips for creating good surveys:

Have goals: the overall survey, and each question, should be expected to provide useful data for your SIG. If you can’t figure out what you’d do with the response to a question, don’t include that question.
Ask more, simpler questions rather than fewer, complex ones.
At the same time, try to produce the shortest survey that will actually give you the data you need.
Remember to include “Don’t Know” or “Not Applicable” options.
Use “Other” options with care, as they tend to generate a lot of garbage input.
Don’t survey too often; survey fatigue will set in an you won’t get responses.

Docs: Discuss Forum Guidelines

Mon, 01 Jan 0001 00:00:00 +0000

Discuss guidelines

Discuss (discuss.kubernetes.io), is the Kubernetes community forum backed by the Discourse discussion platform. It serves as the primary communication platform for Kubernetes users; replacing the kubernetes-users mailing list in September 2018.

Discuss, like other Kubernetes communication platforms, is public and searchable. Communication should be polite and respectful. Follow the general guideline of “be excellent to each other”.

Reference Links:

A community forum for Kubernetes KEP
Archive k-users - kubernetes-users mailing list migrated to Discuss

Code of conduct

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

Privacy Policy

Discuss adheres to the Linux Foundation Privacy Policy.

Admins

Check the centralized list of administrators for contact information.
Discuss administrators are listed on Discuss About page.

To connect: please reach out to them using Discourse’s built in message system. If there is an issue with the platform itself, please use the sig contributor experience mailing list or the #sig-contribex slack channel.

General communication guidelines

PM (Private Message) conversations

Please do not engage in proprietary company specific conversations in the Kubernetes Discourse instance. This is meant for conversations around related Kubernetes open source topics and community. Proprietary conversations should occur in one of your company communication platforms. As with all communication, please be mindful of appropriateness, professionalism, and applicability to the Kubernetes community.

Escalating and/or reporting a problem

Discourse has a built in system for flagging inappropriate posts that will notify the admins of a potentially bad post or conversation. If the post occurred during a period where one of the Admins may not be available, reach out to one of the moderators in the closest timezone directly. As a moderator, they can flag the post which will unlist it immediately until an Admin is available to review it.

If there is an issue in one of the Regional Boards, engage with one of the Regional moderators as a first step. They will be able to add context and aid in the escalation process.

If the problem is with one of the Admins or Moderators, reach out to one of the other Admins and describe the situation.

If it is a [Code of Conduct] issue, contact conduct@kubernetes.io and describe the situation.

Moderation

Discourse has a built in set of advanced auto-moderation capabilities that rely on their "user trust system". For example, newly created accounts are rate limited on posting or replying to topics until their “trust level” increases. A user’s trust level will increase based on a number of factors including time spent on the forum, posts or replies made, likes received, or one of several other metric.

Moderators, both those for the General Forum and Regional Board are manually promoted by an Admin to Trust Level 4. With that comes the full responsibilities of a board moderator.

Moderator expectations and guidelines

Moderators should adhere to the general Kubernetes project moderation guidelines.

Other moderator responsibilities

Ingest queue

Moderators have access to a private category called “Ingest” that has topics posted automatically from a variety of Kubernetes/CNCF sources such as Kubernetes releases, Security Announcements, the kubernetes.io blog, and other useful sources such as Last Week in Kubernetes Development (LWKD). Moderators are encouraged to tag and move these articles to their relevant category.

New category requests

Requesting a general category

New category requests should be posted to the Site Feedback and Help section. Proposed Categories should be community focused and must be related to Kubernetes project. They must not be Company specific with the exception of Cloud providers; however their topics should not be related to proprietary information of the provider.

Once a request has been made, you are encouraged to solicit user support for the category from the community. The admins will review the request, if two express their support for category, it will be created.

Once created, the “About the Category” should be updated with a brief description of the newly created category.

Requesting a SIG, WG, or sub-project category

If you are associated with a SIG, WG or subj-project and would like a Discuss category to collaborate with others asynchronously; post a message with the category creation request to the Site Feedback and Help section. An admin will reach out and provide you with a URL and mail address to use for your discussions.

Requesting a regional category

The Regional Discussions Category is intended for those users that belong to a specific region or share a common language to openly interact and connect with each other in their native language.

The anti-spam and anti-harassment features built into Discourse do not handle other languages as well as it does English. It can pick up on general spam but lacks regional context. For this reason, the Regional categories require additional native-language moderators.

To request the creation of a new Regional board, post the request the top level Regional Discussions Category. If possible solicit additional support from the regional community and propose potential moderators. Before a Regional Board can be created, there must be at least one moderator, preferably two with at least one in the Region’s primary time zone.

Once moderators have been selected, the Regional category can be created.

The first post of the new board “About the Category” post should contain the following text in both english and the region’s language:

Welcome to the <region> category of the Kubernetes Forum! In here you can chat
and discuss topics of interest to you about Kubernetes in [region language].
This is a place to share Kubernetes related news, projects, tools, blogs and
more. This site is governed by the [CNCF Code of Conduct], and we are committed
to making this a welcoming place for all. If you have any specific questions or
concerns, please contact one of the moderators for the <region> category listed
below.
**Moderator Team:**
- <moderator 1>
- <moderator 2>
[CNCF Code of Conduct]: <Translated CNCF Code of Conduct>

The “CNCF Code of Conduct” link should be linked to one of the translated versions of the CNCF Code of Conduct. If none is available, create an issue under the CNCF foundation project requesting the new translation, and link to the English version until a translated version is made available.

Lastly, update the discuss admins section in the moderators.md list with the new region, the moderators and their timezone.

Docs: Mailing List Guidelines

Mon, 01 Jan 0001 00:00:00 +0000

Mailing list guidelines

The Kubernetes mailing list or Google Groups functions as the primary means of asynchronous communication for the project’s Special Interest Groups (SIG), Working Groups (WG), and large subprojects.

Code of conduct

The Kubernetes project adheres to the community Code of Conduct throughout all platforms and includes all communication mediums.

Admins

Check the centralized list of administrators for contact information.

To connect: Reach out to one of the listed moderators, mailing list owners, the SIG Contributor Experience mailing list or the #sig-contribex slack channel.

Mailing list owners

Mailing list owners should include the Chairs for your SIG or WG, or the leads for your subproject, and the below contacts:

contributors@kubernetes.io

Moderation

SIG, Working Group, and subproject mailing lists should have the mailing list owners as co-owners to the list so that administrative functions can be managed centrally across the project.

Moderation of the SIG/WG/subproject lists is up to that individual SIG/WG/subproject. The admins are there to help facilitate leadership changes, or various other administrative functions.

Users who are violating the Code of Conduct or other negative activities (like spamming) should be moderated.

Lock the thread immediately so that people cannot reply to the thread.
Delete the post.
In some cases you might need to ban a user from the group, follow these instructions on how stop a member from being able to post to the group. For more technical help on how to use Google Groups, check the Groups Help page.

Moderator expectations and guidelines

Moderators should adhere to the general Kubernetes project moderation guidelines.

New user posting queue

New members who post to the mailing list will automatically have their messages put in the moderation queue. Moderators of the list will receive a notification of their message and should process them accordingly.

Annual permissions review

SIG, WG, and subproject Moderators must establish an annual review of their mailing lists to ensure their Moderator list is current and includes mailing list owners. Many of the SIG and WG mailing lists pre-date current communication policy and an annual review ensures ownership is up to date.

This review does not need to occur at a specific recurring date and can be combined with other actions such as SIG/WG/subproject leadership changes or sub-project additions.

Mailing list creation

All SIGs and WGs require two discussion groups: one for leads/chairs, and one for members. Subprojects that opt to have a mailing list only require one for members.

Prerequisites for creating a mailing list

An email account that can create Google Groups and add members external to your organization to a Google Group mailing list. This might not be possible with your employer’s email account. You might need to use a personal email account.
At least 3 mailing list owners (leads), in addition to contributors@kubernetes.io
Familiarity with the moderation guidelines for the project and moderation queues. Chairs should be cognizant that a new group will require an initial time investment moderation-wise as the group establishes itself.

Create the leads and members mailing lists

Note: You will need follow these steps twice! Once for the leads mailing list, and again for the members mailing list.

Navigate to https://groups.google.com/forum/#!creategroup and fill out the Enter group info form as follows:

Field	Leads ML value	Members ML value
Group name	SIGs: `kubernetes-sig-<foo>-leads` WGs: `kubernetes-wg-<foo>-leads`	SIGs: `kubernetes-sig-<foo>` WGs: `kubernetes-wg-<foo>` Subprojects: `kubernetes-<foo>`
Group email address	Leave as-is	Leave as-is
Group description	Leads ML for Kubernetes [SIG/WG] Foo	Members ML for Kubernetes [SIG/WG/subproject] Foo

Click Next.

Fill out the Choose privacy settings with these options:

Field	Leads ML value	Members ML value
Who can see the group	Group members	Anyone on the web
Who can join group	Invited users only	Anyone on the web
Who can view conversations	Group members	Anyone on the web
Who can post	Anyone on the web	Anyone on the web
Who can view members	Group members	Group members

Click Next.

Fill out the Add members form as follows:

Field	Leads ML value	Members ML value
Group owners	All SIG/WG leads and contributors@kubernetes.io	All SIG/WG/subproject leads and contributors@kubernetes.io

Note: You can add new owners to a mailing list at any time in the People > Members screen.

Leave all other fields as-is. Click Next.

Once the group is created, navigate to your group in the Google Groups UI and go to Group settings to continue setting up permissions. Set the following settings:

Member Privacy

Field	Leads ML value	Members ML value
Identification required for new members	Either display name or Google profile	Either display name or Google profile
Who can view the member’s email addresses?	Group managers	Group managers

Posting policies

Field	Leads ML value	Members ML value
Conversation history	On	On
Who can moderate content	Group managers	Group managers
Who can moderate metadata	Group members	Group members
Who can post as the group	Group owners	Group owners
Message moderation	No moderation	Moderate messages from non-members
New member restrictions	No posting restriction for new members	New member posts are moderated

Email options

Field	Leads ML value	Members ML value
Subject prefix	SIGs: `[k8s-sig-<foo>-leads]` WGs: `[k8s-wg-<foo>-leads]`	SIGs: `[k8s-sig-<foo>]` WGs: `[k8s-wg-<foo>]` Subprojects: `[k8s-<foo>]`
Email footer	Include the standard Groups footer	Include the standard Groups footer
Group email language	English (or your group’s default language)	English (or your group’s default language)

Member moderation

Field	Leads ML value	Members ML value
Who can manage members	Group managers	Group managers
Who can adjust roles	Group managers	Group managers

Click Save changes. Once your mailing list is created, it should also be added to the sigs.yaml file. For subprojects, it should be added like:

- name: Foo
 contact:
 mailing_list: [link to Google Group]

Set up shared calendars and meeting with a mailing list

Once you’ve set up your SIG/WG mailing list, you’ll need to:

Share a calendar with meeting invites on it with the mailing list
Share a meeting notes google doc with the mailing list

A member’s Google Group.
A shared calendar.

Note: Like with mailing lists, your organization’s permissions might not let you share calendars with the correct permissions. You might need to use a personal email address.

You must share the meeting calendar with the following people:

All leads (individually)
The kubernetes-[sig-/wg-]foo-leads mailing list
contributors@kubernetes.io
The kubernetes-[sig-/wg-]foo (members) mailing list

In Google Calendar, click on the calendar’s … menu and select Settings and sharing.
In Access permissions, check Make available to public.
Under Share with specific people, do the following:

For each lead, contributors@kubernetes.io, and sig-foo-leads@kubernetes.io or kubernetes-sig-foo-leads@googlegroups.com (depending which group is active):
1. Add their email
2. Give them the permission Make changes and manage sharing.
For sig-foo@kubernetes.io or kubernetes-sig-foo@googlegroups.com (depending which group is active), add them and give them the permission See all event details.

Note: You need to add the member’s mailing list as a guest to any meeting invites on the shared calendar for an invite to be sent to members of the group.

Create and share your “meeting notes” Google doc with the following permissions settings:
- Can edit for members of the newly created Mailing List.
- Can comment for dev@kubernetes.io
- View only for anyone with the link. NOTE: Depending on employer organization policy, this may not be possible to configure. The document should be copied over to an account without the restriction and include the owner reference at the top of the document.

Archive a mailing list

To archive a mailing list, use the below procedure.

Send a final notice to the mailing list that it is closed. This notice should include a brief description as to why and include links to any other relevant information.
From the Google Groups management page goto Information -> General Information.
- Configure the following settings:
  - Group description -> Set to the same message used for the final mailing list notice.
From the Google Groups management page goto Information -> Content Control.
- Configure the following settings:
  - Archive messages to the group -> checked
From the Google Groups management page goto Permissions -> Basic permissions.
- Configure the following settings:
  - View Topics:
    - Managers of the group
    - All members of the group
    - Anyone on the web
  - Post: -> uncheck all options
  - Join the group:
    - Only invited users

Docs: Moderation Rules and Responsibilities

Mon, 01 Jan 0001 00:00:00 +0000

Moderation on Kubernetes Communications Channels

This page describes the rules and best practices for people chosen to moderate Kubernetes communications channels. This includes Github, Slack, forums, mailing lists, YouTube, Zoom, and any property listed in the SIG Contributor Experience charter.

Check the centralized list of administrators for contact information.
Some Kubernetes properties, like the Twitter account, are managed by the CNCF.

Selection of Moderators

Each Kubernetes property has a certain set of moderators who are responsible for keeping it safe and a fun place to participate.

Moderators are selected by following the criteria:

Moderators MUST:

Be a member of the Kubernetes Organization.
Have experience moderating something or some equivalent level of community management.
Make themselves available during their primary working hours for their given timezone.
Communicate their availability to their peer moderators when appropriate, such as when travelling or becoming unavailable for an extended period of time.
Understand that volunteering for this role might mean an occasional personal time commitment or off-hour duty.

The process for applying for moderatorship is as follows:

Sponsored by 2 existing moderators Note the following requirements for sponsors:
- Sponsors MUST have close interactions with the prospective member - example: participating in the appropriate property, coordinating on issues, etc.
- Sponsors MUST be from multiple member companies to demonstrate integration across community.
- Sponsors MUST take time zone coverage into account, each property should have global coverage. Ideally no more than two(2) moderators are needed in a given time zone.
- Sponsors MUST ensure that nominees are familiar with the software they are using to moderate.
Open an issue against the kubernetes/community repo
- Ensure your sponsors are @mentioned on the issue.
- Complete every item on the checklist
- Make sure that the list of contributions included is representative of your work on the project.
Have your sponsoring reviewers reply confirmation of sponsorship: +1 or similar approval.

Moderators Pro Tempore

Each property will have a list of moderators who cannot commit to full time moderatorship, but are available during special events or circumstances that might call for additional ad-hoc duties.

For example if all moderators are attending a conference, pro tempore moderators may be assigned to monitor a property.

Rotation of Moderators

Content moderation can be personally tiring, so primary Moderators SHOULD rotate on a regular basis.

Primary moderators should evaluate their position(s) as a team yearly.
- Determine whether the moderation situation on the property is working.
- Rotate teams accordingly.
- Consider rotating in less experienced person to give them an opportunity to participate.
- Take into account time zone considerations.
Due to less workload Moderators Pro Tempore should be a lightweight role
- Primary moderators should consider switching to this role for a given amount of time to allow for a healthy rotation.

Roles and Responsibilities

As part of volunteering to become a moderator you are now a representative of the Kubernetes community, and it is your responsibility to remain aware of your contributions in this space. These responsibilities apply to all Kubernetes official channels.

Moderators MUST:

Take action as specified by these Kubernetes Moderator Guidelines.
- You are empowered to take immediate action when there is a violation. You do not need to wait for review or approval if an egregious violation has occurred. Make a judgement call based on our Code of Conduct and Values (see below).
- Removing a bad actor or content from the medium is required, do NOT let it sit there.
Abide by the documented tasks and actions required of moderators.
Ensure that the Kubernetes Code of Conduct is in effect on all official Kubernetes communication channels.
Make yourself generally available during working hours in your time zone for moderation.
- This can be handled as a group so that there is enough coverage of people to allow for absences/travel.
- Ensure you are on #slack-admins during work hours and notifications are set appropriately.
Become familiar with the Kubernetes Community Values.
Take care of spam as soon as possible, which may mean taking action by removing a member from that resource.
Foster a safe and productive environment by being aware of potential multiple cultural differences between Kubernetes community members.
Understand that you might be contacted by moderators, community managers, and other users via private email or a direct message.
Keep up with software/platform changes on the property they are responsible for. This might include new UI changes, new features, or other software changes. Moderators are encouraged to meet regularly to train themselves how to be proficient with the platform.
Report violations of the Code of Conduct to conduct@kubernetes.io.

Moderators SHOULD:

Exercise compassion and empathy when communicating and collaborating with other community members.
Understand the difference between a user abusing the resource or just having difficulty expressing comments and questions in English.
Be an example and role model to others in the community. In many cases, moderators are some of the first people new contributors will interact with.
Remember to check and recognize if you need take a break when you become frustrated or find yourself in a heated debate.
Help your colleagues if you recognize them in one of the stages of burnout.
Be helpful and have fun!

Violations

The Kubernetes Code of Conduct Committee will have the final authority regarding escalated moderation matters. Violations of the Code of Conduct will be handled on a case by case basis. Depending on severity, this can range up to and including removal of the person from the community, though this is extremely rare. This decision comes from the Code of Conduct committee, not the moderators.

Escalation Procedures

In the event of large attacks the moderator team must enact the following procedures:

The person on call should immediately concentrate on removing the offending content and asking for other on call moderators for help. That is their sole responsibility.
The secondary person on call should immediately begin to take notes to document the incident, this will form the basis of a post-mortem. The 2nd person on site is responsible for finding help, and documenting the incident.
The secondary person on call will escalate if necessary. If it’s a one off incident and the content is removed, then the collective moderators can work on a post-mortem and report the incident to primary moderators within 24 hours.
- If it’s a sustained incident that needs more help, the secondary will contact other primary moderators as soon as possible.
- If appropriate, the next level of people to contact are the OWNERS of the subproject.
- If appropriate, the next level of people to contact is the Code of Conduct Committee.
- If appropriate, the next level of people to contact is the Steering Committee.
Moderators will have access to a private document with contact information of the appropriate people.
Primary moderators will then execute an audit of the affected property:
- Slack: emoji audit
- (More per-property steps to be added as we learn them)

Escalation to Code of Conduct Committee Procedures

In the event of a violation of the Code of Conduct, the moderators will use the following procedures to escalate the issue to the Code of Conduct Committee:

If you believe that a poster is violating the Kubernetes Community Code of Conduct, escalate the matter to the Code of Conduct Committee. Include the following to the best of your ability in that message:

A statement of the seriousness of the matter, what is the urgency of response?
A statement of the nature of the violation with links to the offensive posts. It is useful to take a screenshot to preserve potentially ephemeral evidence.
Include the contents of whatever conversations you have had with the poster in your capacity as moderator that are relevant to this matter.
If there are historical details that are relevant also mention them.

Platform Specific Guidelines

These guidelines are for tool-specific policies that don’t fit under a general umbrella.

Discuss

Mailing List

Slack

YouTube

Moderators should check the Comments section in the community tab regularly for published comments and the “hold for review” sections to see if comments are being flagged by the system.
We do NOT use YouTube comments during our live streams, these are checked as OFF in the settings.
Youtube Guidelines
Moderators

Zoom

Process for Adding a Moderator

This is the workflow for adding a moderator.

Moderator applies by filing an issue in the kubernetes/community repo
Moderator gets approval from 2 current moderators
Add the person to their respective moderation tool:
- Slack - Add them as a slack workspace admins (instructions pinned on #slack-admins-private): Invite them to #slack-admins-private, #slack-admins, #slack-log, #slack-reports and #slack-invites
- Discuss - Change their permission to moderator
- Kubernetes.io Google group - PR the person into the correct yaml file in kubernetes/k8s.io. (Note: This only applies to groups using @kubernetes.io, most other lists are still managed out of band)
- Ensure they add that they are an admin in their profile page on whatever service they are administrating
Add them to the moderators mailing list by PRing them into the moderators@kubernetes.io group linking to the person’s moderator github application as part of the PR.
Ensure person is enrolled for a future bias training course, this can either be provided by the project or their employer.

References and Resources

Thanks to the following projects for making their moderation guidelines public, allowing us to build on the shoulders of giants. Moderators are encouraged to learn how other projects moderate and learn from them in order to improve our guidelines:

Docs: Moderator list

Mon, 01 Jan 0001 00:00:00 +0000

Community Moderators

The following people are responsible for moderating/administrating Kubernetes communication channels and their home time zone. See our moderation guidelines for policies and recommendations.

Mailing Lists

kubernetes-dev

Administrators

Administrator seats: 3

Name	Kubernetes Slack ID	Region	Timezone
Aaron Crickenberger	@spiffxp	Americas	PT - Pacific Time (US West Coast)
Davanum Srinivas	@dims	Americas	ET - Eastern Time (US East Coast)

Primary Moderators

Primary moderators seats: 6

Name	Kubernetes Slack ID	Region	Timezone
Bob Killen	@mrbobbytables	Americas	ET - Eastern Time (US East Coast)
Carlos Panato	@cpanato	EMEA	CET - Central European Time
Ihor Dvoretskyi	@ihor.dvoretskyi	EMEA	EET - Eastern European Time
Jaice Singer DuMars	@jdumars	Americas	PT - Pacific Time (US West Coast)
Nabarun Pal	@palnabarun	APAC	IST - Indian Standard Time
Nikhita Raghunath	@nikhita	APAC	IST - Indian Standard Time

Moderators Pro Tempore

Moderators pro tempore seats: 5

Name	Kubernetes Slack ID	Region	Timezone
Atharva Shinde	@Atharva Shinde	APAC	IST - Indian Standard Time
Debabrata Panigrahi	@deba	APAC	IST - Indian Standard Time

GitHub

Note that this team is not only responsible for the project’s Github administration, but also moderation of issues, PRs, etc.

GitHub Administration Team

Discuss

Administrators

Administrators seats: 4

Name	Kubernetes Discuss ID	Region	Timezone
Bob Killen	@mrbobbytables	Americas	ET - Eastern Time (US East Coast)
Chris Carty	@cartyc	Americas	ET - Eastern Time (US East Coast)
Jorge Castro	@castrojo	Americas	ET - Eastern Time (US East Coast)
Josh Berkus	@jberkus	Americas	PT - Pacific Time (US West Coast)
Rael Garcia	@raelga	Europe	CET - Central European Time
Marky Jackson	@markyjackson-taulia	Americas	PT - Pacific Time (US West Coast)

Note, due to how the software is designed, dedicated moderators are not required for discuss, the trust system in place allows for self moderation. In this case administrators act as exception handlers. Regional moderators are required for language/cultural reasons, (ie. we can’t expect a community member who doesn’t speak a language to be able to effectively moderate).

Regional Category Moderators

Regional category moderators seats (per category): 3

Chinese

Name	Kubernetes Discuss ID	Region	Timezone
Peter (Xiang Peng) Zhao	@xiangpengzhao	APAC	CST - China Standard Time
Yang Li	@idealhack	APAC	JST - Japan Standard Time
Puja Abbassi	@puja	EMEA	CET - Central European Time

German

Name	Kubernetes Discuss ID	Region	Timezone
Puja Abbassi	@puja	EMEA	CET - Central European Time
Michael Hausenblas	@mhausenblas	EMEA	WET - Western European Time

Italian

Name	Kubernetes Discuss ID	Region	Timezone
Jacopo Nardiello	@jnardiello	EMEA	CET - Central European Time
Open	Open

Spanish

Name	Kubernetes Discuss ID	Region	Timezone
Rael Garcia	@rael	EMEA	CET - Central European Time
Open	Open

Ukrainian

Name	Kubernetes Discuss ID	Region	Timezone
Ihor Dvoretskyi	@idvoretskyi	EMEA	EET - Eastern European Time
Open	Open

Hindi

Name	Kubernetes Discuss ID	Region	Timezone
Jayesh Mahajan	@jayeshmahajan	Americas	ET - Eastern Time (US East Coast)
Open	Open

YouTube Channel

Owners

Email: contributors@kubernetes.io

Primary Moderators

Moderators seats: 6

Name	Kubernetes Slack ID	Region	Timezone
Chris Short	@chrisshort	Americas	ET - Eastern Time (US East Coast)
Nigel Brown	@nigel	Americas	CT - Central Time (US Central)
Pritish Samal	@Pritish	APAC	IST - Indian Standard Time
Chad Crowell	@chadmcrowell	Americas	CT - Central Time (US Central)
Open	Open	Open	Open

Backup Moderators

Name	Kubernetes Slack ID	Region	Timezone
Jeffrey Sica	@jeefy	Americas	ET - Eastern Time (US East Coast)
Bob Killen	@mrbobbytables	Americas	ET - Eastern Time (US East Coast)

Slack

Owner

Owners seats (non-admin role): 3

Name	Kubernetes Slack ID	Region	Timezone
Chris Aniszczyk	@caniszczyk	Americas	CT - Central Time (US Central)
Bob Killen	@mrbobbytables	Americas	ET - Eastern Time (US East Coast)
Ihor Dvoretskyi	@ihor.dvoretskyi	Europe	EET - Eastern European Time

Moderators

Moderators seats: 10

Name	Kubernetes Slack ID	Region	Timezone
Jorge Castro	@castrojo	Americas	ET - Eastern Time (US East Coast)
Jeffrey Sica	@jeefy	Americas	ET - Eastern Time (US East Coast)
Bob Killen	@mrbobbytables	Americas	ET - Eastern Time (US East Coast)
Jorge Alarcon	@alejandrox1	Americas	ET - Eastern Time (US East Coast)
Katharine Berry	@Katharine	Americas	PT - Pacific Time (US West Coast)
Jaice Singer DuMars	@jdumars	Americas	PT - Pacific Time (US West Coast)
Noah Kantrowitz	@coderanger	Americas	PT - Pacific Time (US West Coast)
Ihor Dvoretskyi	@ihor.dvoretskyi	EMEA	EET - Eastern European Time
Yang Li	@idealhack	APAC	JST - Japan Standard Time
Josh Berkus	@jberkus	Americas	PT - Pacific Time (US West Coast)
Marky Jackson	@markyjackson-taulia	Americas	PT - Pacific Time (US West Coast)
Open	Open

Moderators Pro Tempore

Moderators pro tempore seats: 10

Name	Kubernetes Slack ID	Region	Timezone
Dylan Graham	@DylanGraham	APAC	AET - Australian Eastern Time
Angus Lees	@anguslees	APAC	AET - Australian Eastern Time
Aditya Konarde	@aditya-konarde	APAC	IST - Indian Standard Time
Manjunath Kumatagi	@mkumatag	APAC	IST - Indian Standard Time
Pandiyaraja Ramamoorthy	@pontiya	APAC	IST - Indian Standard Time
Puja Abbassi	@puja108	EMEA	CET - Central European Time
James Munnelly	@munnerz	EMEA	GMT - Greenwich Mean Time
Joel Speed	@JoelSpeed	EMEA	GMT - Greenwich Mean Time

Zoom

Administrators seats: 6

Name	Kubernetes Slack ID	Region	Timezone
Jorge Castro	@castrojo	Americas	ET - Eastern Time (US East Coast)
Bob Killen	@mrbobbytables	Americas	ET - Eastern Time (US East Coast)
Jorge Alarcon	@alejandrox1	Americas	ET - Eastern Time (US East Coast)
Naeil Ezzoueidi	@nzoueidi	EMEA	CET - Central European Time
Yang Li	@idealhack	APAC	JST - Japan Standard Time
Jeffrey Sica	@jeefy	Americas	ET - Eastern Time (US East Coast)
Ihor Dvoretskyi	@ihor.dvoretskyi	EMEA	EET - Eastern European Time
Marky Jackson	@markyjackson-taulia	Americas	PT - Pacific Time (US West Coast)
Nigel Brown	@nigel	Americas	CT - Central Time (US Central)
Chris Short	@chris-short	Americas	ET - Eastern Time (US East Coast)

License and main account controlled by the CNCF

Docs: Notification Management Best Practices

Mon, 01 Jan 0001 00:00:00 +0000

Mailing list and GitHub notification best practice

The Kubernetes Mailing list or Google Groups functions as the primary means of asynchronous communication for the project’s Special Interest Groups (SIG) and Working Groups (WG). That’s why you may want to set your filters in your email account to attain a good signal-to-noise ratio with regards to the mailing list messages and GitHub notifications. All the steps below are for Gmail users, however similar filters can be made in other email clients.

Creating filters for Kubernetes Mailing lists

It depends on the SIG or/and WG you are involved in. You can setup filters for your Gmail account to be able to categorize emails from different mailing lists.

Create a filter following the procedure below:

In your Gmail account click on Settings:
- Filters and Blocked Addresses -> Scroll down and click create a new filter
- In the to fields write the email of the SIG’s Google Group.
- Create filter -> Check the box ** Apply the label** and create new label by choosing New label… in the dropdown list.
- Click on the Create filter.
Create filter directly for lists:
- Matches: list:“dev@kubernetes.io”
- Do this: Apply label “lists/kubernetes-dev”

For more assistance on creating filters, see the Gmail help page on Creating rules to filter your email.

Creating filters for Kubernetes Github notifications

These below suggested Gmail filters can help you organize and obtain better signal GitHub notification emails.

Before you begin, you must know how to create filters in Gmail. For this procedure, see the Gmail help page on Creating rules to filter your email.

Apply a blue label on anything kubernetes-related:
- Matches: (kubernetes OR kubernetes-client OR kubernetes-sigs OR kubernetes-csi)
- Do this: Apply label “k8s”, Mark it as important
Archive your own actions (sending these is an option in Github’s settings). You can send them but also archive them, so whenever you need to see the history of an issue you can:
- Matches: to:(your_activity@noreply.github.com)
- Do this: Skip Inbox, Mark as read
Skip bot comments:
- Matches: (from:(notifications@github.com) (from:(k8s-merge-robot) OR from:(Kubernetes Prow Robot) OR from:(k8s-ci-robot)))
- Do this: Skip Inbox, Mark as read
Skip push notifications:
- Matches: to:(push@noreply.github.com)
- Do this: Skip Inbox, Mark as read
Apply a red label on things assigned to you and/or things request to be reviewed:
- Matches: to:(assign@noreply.github.com)
- Do this: Star it, Apply label “gh/assigned”, Mark it as important
- Matches: to:(review_requested@noreply.github.com)
- Do this: Star it, Apply label “gh/requested_review”, Mark it as important
Apply an orange label on things you commented on:
- Matches: to:(comment@noreply.github.com)
- Do this: Star it, Apply label “gh/commented”
Apply a yellow label on things you have been mentioned on:
- Matches: to:(mention@noreply.github.com)
- Do this: Apply label “gh/mentioned”
Apply a grey label:
- Matches: to:(team_mention@noreply.github.com)
- Do this: Apply label “gh/team_mention”
- Matches: to:(author@noreply.github.com)
- Do this: Star it, Apply label “gh/authored”, Mark it as important
Skip messages about issues that you are not participating in, but leave them unread:
- Matches: from:(notifications@github.com) to:(subscribed@noreply.github.com)
- Do this: Skip Inbox
Categorize per repository:
- Matches: list:(community.kubernetes.github.com)
- Do this: Apply label “k8s/community”

These suggestions come largely from an old kubernetes-dev mailing list thread on Gmail filters for Kubernetes.

Docs: Slack Guidelines

Mon, 01 Jan 0001 00:00:00 +0000

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 150,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.

Admins

Check the centralized list of administrators for 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.

General Communication Guidelines

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

Slack Usage Rules

In addition to the Code of Conduct, users of Kubernetes Slack must adhere to the following behavior rules. Failure to follow them may result in warnings, removal of posts, escalating to temporary or permanent deactivation of the user account.

Adhere to Channel Topics: for the most part, try to stick to the declared topic of the channel you’re in.
No 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 Unsolicited DMs: do not send any user uninvited direct messages (DMs).
Don’t Discuss Company Business: Proprietary conversations should occur in your company Slack and/or communication platforms.
No Surveys: surveys, focus groups, free trials, and similar calls for participation are considered spam and are prohibited. Exceptions: an official Kubernetes community survey can be posted anywhere, and any survey may be posted to the Surveys channel.
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, except for the #events channel. Generally, this only includes 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.
#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. You may also post resumes if you are looking to be hired. Job postings must include:
- A link to the posting or job description.
- The business name that will employ the Kubernetes hire.
- The location of the role or if remote is OK.
#surveys - Cloud native community wide surveys. Posts must be ecosystem related.

Escalating and/or 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, 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).

A Slack admin or CoCC member will work to resolve the issue or reach out for more information.

If the issue has not been responded to in a timely manner, 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.

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.

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.

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.

Moderation

Admin Expectations and Guidelines

Admins should adhere to the general Kubernetes project moderation guidelines.

Additionally, admins should ensure they have 2-factor auth enabled for their account and mention they are a Slack admin in the “What I do” portion of their profile. This message should also include the time zone they are representing.

Be mindful of how you handle communication during stressful interactions. Administrators act as direct representatives of the community, and need to maintain a very high level of professionalism at all times. If you feel too involved in the situation to maintain impartiality or professionalism, that’s a great time to enlist the help of another admin.

Try to take any situations that involve upset or angry members to DM or video chat. Please document these interactions for other Slack admins to review.

Content will be removed if it violates code of conduct or is a sales pitch. Admins will take a screenshot of such behavior in order to document the situation. The community takes such violations extremely seriously, and the admins are empowered to handle it swiftly.

Sending Messages to the Channel

@all, @here and @channel should be used rarely. Members will receive notifications from these commands. Remember Kubernetes is a global project—please be kind.

Processing Slack Requests

Admins are tasked with processing requests for channels and other things such as bots, tokens or webhooks. Please see the processes outlined below.

Processing Channel Requests

Channel requests should be reviewed for their relation and relevance to the Kubernetes community. Typically channels should be dedicated to SIGs, WGs, sub-projects, community topics, and other things related to Kubernetes programs and projects.

For Kubernetes project centric requests, validate them against the sig-list, or request a link to a related issue/PR, or mailing list discussion for the requested Channel.

Small external projects are encouraged to use the channel of the SIG or WG most relevant to them. Other things such as programming language-specific channels are discouraged and should in turn be steered to #kubernetes-client or communication avenues commonly used by their specific language.

In general, use your best judgment.

Once two Slack admins have reviewed and agreed to sponsor the channel, they will sign off on the Channel Request PR. Once merged, the channel will be created.

Channels managed by Tempelis will automatically have default messages pinned. For any manually-provisioned channels, such as private channels, add the below message and pin it.

This channel abides to the Kubernetes Code of Conduct -
https://git.k8s.io/community/code-of-conduct.md
Contact conduct@kubernetes.io or an admin in the #slack-admins channel if there
is a problem.

Processing User Group Requests

User Group requests should be reviewed for their relation and relevance to the Kubernetes community along with their importance to the requesting group. They are a useful alias, but can also easily be spammed or abused.

Before signing off on a User Group PR request, ensure all members of the User Group have signed off acknowledging they will be added to the group.

After all the User Group members have accepted being added to the group and two Slack Admins have signed off on the request, the PR will be merged. Once merged, the User Group will be created.

Processing Bot, Token, or Webhook Requests

Requests should first be evaluated for their relevance to the project. Typically approved requests are related to: GitHub, the CNCF, or other tools and platforms used to aid in the management of Slack. Requests outside of this scope should be heavily scrutinized and reviewed for ANY potential security, privacy, or usability concerns.

It is best to err on the side of not allowing a bot, token, or webhook request rather than allowing one.

If the admins come to consensus and agree to the request, an admin should assign the issue to themselves and reach out to the request contact regarding next steps.

Inactivating Accounts

For the reasons listed below, admins may inactivate individual Slack accounts. Due to Slack’s framework, it does not allow for an account to be banned or suspended in the traditional sense, merely inactivated. See Slack’s policy on inactivated accounts for more information.

Reasons to inactivate an account

Spreading spam content in DMs and/or channels.
Not adhering to the code of conduct set forth in DMs and/or channels.
Overtly selling products, related or unrelated to Kubernetes.

BE CAREFUL

To inactivate a user, and optionally remove their content (spam):

First, double check you have the correct user by verifying their Slack Member ID.
Spammers may try and fake or assume the identity of another user.

Once verified, find a message from the offending user. Then select More actions, the “…” to the right of a message from the offending user. Then select Report message.

This will open a contextually-aware prompt only available to Slack Admins with the options to deactivate the user and remove all content from them over the past “X” minutes/hours.

Report any actions taken to the other slack admins, and if needed the Code of Conduct Committee.

Docs: YouTube Channel Guidelines

Mon, 01 Jan 0001 00:00:00 +0000

YouTube serves as the primary means of distribution for recorded Kubernetes community content including Zoom recordings, official project workshops and Contributor Summit sessions.

Code of Conduct

Kubernetes adheres to the Kubernetes Code of Conduct throughout the project, and includes all communications such as YouTube.

Admins

Check the centralized list of administrators for contact information.
To contact the admin group in Slack, ping @youtube-admins in the #sig-contribex Slack channel.

Meeting Playlists

The Kubernetes YouTube Channel has separate playlists for each SIG or WG meeting recordings, as well as recordings of other recurring events such as the Kubernetes community meeting, and others.

Subprojects, in addition to SIGs and WGs may request their own playlists to better target their contributors and increase general discoverability.

To better serve the community, collaboration has been enabled to share the management of the playlists. Anyone with the appropriate link to the particular playlist can upload videos to that particular playlist (links & playlists are one-to-one).

Each group’s playlist link will be shared with the group’s leadership via Slack and the group leadership Google Group. Other playlists links, will be shared with the appropriate point(s) of contact.

Uploading Guidelines for Collaborators

NOTE: If you’re using a Google Workspace account (formerly known as G Suite) you may need to update the permissions in your YouTube settings. If you have any questions, reach out to the YouTube admins or SIG Contributor Experience. You may need to reach out to someone at your organization if you do not have access to Google Workspace Admin permissions.

NOTE: Both public and private steering meeting recordings should be made public.

With collaboration comes great responsibility. Playlist collaborators in the community must use it responsibly and are subject to the following guidelines:

Group leaders or other appropriate point(s) of contact are the primary managers for the playlist, once collaboration is configured. YouTube admins should only be contacted if the issue cannot be resolved by one of the playlist owners.
Upload responsibilities belong to the group leaders or other appropriate contacts. YouTube admins should only be contacted if the issue cannot be resolved by the playlist owners.
Please post only related content, for example meeting recordings, in the appropriate playlists.
- Posting of any inappropriate content (i.e. NSFW content) will result in immediate suspension of privileges.
All posted videos should use the naming convention: [Name of Playlist’s Group] Meeting Name for YYYYMMDD
- Example: SIG Contributor Experience Biweekly Meeting for 20240816
Playlists should be organized chronologically for ease of use. This can be done by updating the default ordering of the Playlist:
- From within the Playlist settings, click on the Basic Tab.
- From the Ordering dropdown select “Date added (newest)”.
- Save the changes and the order should automatically be updated.
Please do not remove any already-published content from the playlists without checking with the YouTube admins.
For any small issues that arise, for example improper naming or ordering, you may be asked by the YouTube admins to attempt to resolve the issue yourself.
Any egregious or habitual violations (3 or more per quarter) of the above rules will result in suspension of collaboration privileges for the particular individual or for the entire playlist if the individual can’t be identified.
- If an individual is suspended, the playlist link will be remade and the new link will be shared with the non-offending individuals.
- If playlist collaboration is suspended, the uploading and management of the playlist will be handled by the YouTube admins. Uploading the problematic group’s playlist will not be considered a priority, and delays in uploading should be expected.

Admin Responsibilities

The role of the Youtube Admins is to help maintain a robust YouTube channel that is valuable to contributors and upholds our transparency goals as laid out by our governance documents.

Moderator Expectations and Guidelines

Moderators should adhere to the general Kubernetes project moderation guidelines.

Moderation responsibilities for YouTube admins is minimal and is centered around checking and removing any potential comments that would violate the Code of Conduct. Any potential violations should be sent to conduct@kubernetes.io.

Trimming and Editing Recordings

YouTube admins are asked to help trim and edit recordings that come into the video queue.

Examples:

Certain events such as the Contributor Summits are not uploaded directly to YouTube and require editing.

A Zoom recording may have significant dead-space leading the meeting itself and also at the end as we end the stream.

A SIG Meeting needs to be edited to make sure it’s clear (ie “Kubernetes Special Interest Group ContribEx 20220131 Meeting”).

Make sure to save a copy of the video first before making adjustments as this can delete the original if not careful. When in doubt, ask.

Automation

Note: There is always room for improvement! As such, the community is open to trying various integration features or other productivity tools that might improve the job of admins and help make things more streamlined. Please, reach out if you can help or have any ideas.

Splain.io

One feature used by several SIGs is splain.io. This tool creates a pipeline between Zoom and youtube for easier workflows. To use splain.io please follow the steps outlined below.

Items needed to use splain.io:

UserName and Password for the Zoom license account. You will need a Zoom admin or the admin of the license (ex: SIG Chair) to either provide it to you or reset it to a new one.
Kubernetes YouTube admin permissions
A correctly set up recurring meeting with a start and end time (this is important) - check Zoom guidelines for more details

Steps:

Install splain: https://marketplace.zoom.us/apps/WPKzwuoLQDuj_gPs68AQxw
Connect the Zoom account
Connect YouTube account
Click the manage tab next to App Info, and then scroll to locate the config button.
Click Config
The splain dashboard opens: make sure the box for Make videos private is checked so we can edit before it goes live.
Test that it works.
Enjoy.

The following SIGs and groups are currently running splain.io:

SIG Auth
SIG Contributor Experience
SIG Docs
SIG Network
SIG Release
Steering Committee
WG Data Protection
The main Zoom admin account (if you log in to splain using this account, all of the other accounts will be logged here)

Descriptions and Playlists

Each video that comes into the queue needs to be added to a playlist, set to public, and have contextual information added to the description.

Example description:

Kubernetes Contributor Experience Special Interest Group Weekly Meeting. Check here (link to sig list) for a complete list of SIGs and when they meet. Join us!

Please note the following items:

The date must be in title and description
The date format must be YYYYMMDD
The section titled “Is this video made for kids?” should not be altered for search reasons

Below is an example:

Incorrect description: Data Protection WG Bi-Weekly Meeting for 2/26/2020
Correct description: Data Protection WG Bi-Weekly Meeting for 20200226

A short video tutorial of the editing of descriptions and playlists can be found here:

https://youtu.be/IbZ2wnvu_Zs

Thumbnails

There have been ongoing conversations about how to create and manage better thumbnails for videos using some kind of standard. If you’re interested in helping with thumbnails, please reach out to the YouTube Admins. They would love to hear from you.

Streaming Events

YouTube admins with a system capable of streaming may be asked to stream public Kubernetes Community events such as the weekly Community Meeting, or other publicly streamed events. For detailed information about streaming, see our Streaming Config.

Migrating Content

In certain cases, such as archiving an inactive SIG or Working Group, it might be useful to grab content from other channels. It is currently NOT POSSIBLE to move content from one YouTube channel to another, so the content must be downloaded and then reuploaded to the Kubernetes channel.

Download youtube-dl, which makes it easier to bulk download videos.
Download the channel or playlist with: youtube-dl <url>
Clean up the filenames as they are used to generate new titles. Do this locally since it is easier than doing it per video in the YouTube web UI.
Create a new playlist for the content on the Kubernetes channel, set it to Private.
Upload the videos to the Kubernetes Channel.
Ensure titles and metadata are accurate, allow time to pass for YouTube to generate thumbnails and process the videos.
Once videos are finalized, set the playlist to Public to publish them.

Docs: Zoom Guidelines

Mon, 01 Jan 0001 00:00:00 +0000

Zoom is the main video communication platform for Kubernetes. It is used for running the community meeting, SIG/WG meetings, and many other Kubernetes online events. Since the Zoom meetings are open to the general public, a Zoom host or co-host has to moderate a meeting in all senses of the word, from starting and stopping the meeting to acting on Kubernetes code of conduct issues.

These guidelines are meant as a tool to help Kubernetes members manage their Zoom resources.

Check the main moderation page for more information on other tools and general moderation guidelines.

Code of conduct

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

Zoom license management

Zoom licenses are managed by the CNCF Service Desk through the Zoom Admins listed in the centralized list of administrators.

Obtaining a Zoom license

Ensure that all SIG/WG leads, chairs, and any other necessary trusted owners have access to the k-sig-<foo>-leads@googlegroups.com account as described in the sig creation procedure. Once done, contact one of the Zoom Admins to obtain a Zoom license.

Setting up your meeting and moderation

Do not share your Zoom link on social media. This will help curtail trolls and others who would intentionally attempt to disrupt your Zoom call.

To create a meeting with moderation enabled, ensure the following:

Have the latest version of the Zoom client installed.
Be logged in as the leads account associated with the meeting OR use the host key to “claim host”.
Configure a meeting setup through the “Meeting” menu in the leads Zoom account. NOTE: Do NOT use the “Personal Meeting ID”. This will create an “ad-hoc” meeting that is time-bounded and without moderation capability.
Set the password to the meeting to “77777”

After the meeting has started:

Assign a co-host to help with moderation. It should never be your note taker unless it’s a very small group.
Turn off screen sharing for everyone and indicate “only host”. If you have others that need to share their screen, the host can enable that on the fly. (via the ^ menu next to Share Screen)

Moderation

If you’re dealing with a troll or bad actor:

Put the troll or bad actor on hold. The participant will be put into a waiting room and will not be able to participate in the call until the host removes the hold.
- NOTE: Depending on your client version this will be called “Put in Waiting Room” instead of on hold.
Remove the participant. Please be cautious when testing or using this feature, as it is permanent. They will never be able to come back into that meeting ID on that particular device. Do not joke around with this feature; it’s better to put the attendee on “hold” first and then remove.
After an action has been taken, use the lock meeting feature so that no one else can come into the meeting. If that fails, end the call immediately, and contact the Zoom Admins to report the issue.

NOTE: You can find these actions when clicking on the more or "…" options after scrolling over the participants name/information.

Hosts must be comfortable with how to use these moderation tools and the Zoom settings in general. Make sure whoever is running your meeting is equipped with the right knowledge and skills. If you have any questions or concerns, reach out to the Zoom Admins and they will be able to provide further guidance and training.

Zoom has documentation on how to use their moderation tools.
Members of the leads@ group have access to an extensive best practices doc with screenshots going over the community Zoom best practices.

Escalating and Reporting a Problem

Issues that cannot be handled via normal moderation, or with the assistance of the Zoom Admins should be escalated to the Kubernetes Code of Conduct Committee at conduct@kubernetes.io.

To contact the admin group in Slack, ping @zoom-admins in the #sig-contribex Slack channel.

Meeting recordings

Chairs and TLs are responsible for posting all update meetings to their playlist on YouTube. Please follow this guideline for more details.

If a violation has been addressed by a host and it has been recorded by Zoom, the video should be edited before being posted on the Kubernetes channel.

Contact SIG Contributor Experience if you need help to edit a video before posting it to the public.

Zoom has documentation on how to use their screen sharing feature.

Recommendations:

Turn off notification to prevent any interference.
Close all sensitive documents and unrelated programs before sharing the screen. Email notifications are distracting!
Test your presentation beforehand to make sure everything goes smoothly.
Keep your computer background desktop clean. Make sure there are no offensive or distracting visuals.

Audio/Video quality recommendations

While video conferencing has been a real boon to productivity there are still lots of things that can go wrong during a conference video call.

There are some things that are just plain out of your control, but there are some things that you can control. Here are some tips if you’re just getting into remote meetings. Keep in mind that sometimes things just break. These are not hard rules, more of a set of loose guidelines on how to tip the odds in your favor.

Recommended hardware to have

A dedicated microphone - This is the number one upgrade you can do. Sound is one of those things that can immediately change the quality of your call. If you plan on being here for the long haul, something like a Blue Yeti will work great due to the simplicity of using USB audio and having a hardware mute button. Consider a pop filter as well if necessary.
A Video Camera - A bad image can be worked around if the audio is good. Certain models have noise canceling dual-microphones, which are a great backup for a dedicated microphone or if you are traveling.
A decent set of headphones - These cut down on the audio feedback when in larger meetings.

What about an integrated headset and microphone? This totally depends on the type. We recommend testing it with a friend or asking around for recommendations for which models work best.

Earbuds - These are not ideal, and while they might sound fine to you, when 50 people are on a call the ambient noise adds up. Some people join with earbuds and it sounds excellent, others join and it sounds terrible. Practicing with someone ahead of time can help you determine how well your earbuds work.

Pro-tips

Join on muted audio and video in order to prevent noise to those already in a call.
If you don’t have anything to say at that moment, MUTE. This is a common problem. You can help out a teammate by mentioning it on Zoom chat or asking them to mute on the call itself. The meeting co-host can help with muting noisy attendees before it becomes too disruptive. Don’t feel bad if this happens to you, it’s a common occurrence.
Try to find a quiet meeting place to join from; some coworking spaces and coffee shops have a ton of ambient noise that won’t be obvious to you but will be to other people in the meeting. When presenting to large groups consider delegating to another person who is in a quieter environment.
Using your computer’s built-in microphone and speakers might work in a pinch, but in general won’t work as well as a dedicated headset/microphone.
Consider using visual signals to agree to points so that you don’t have to mute/unmute often during a call. This can be an especially useful technique when people are asking for lazy consensus. A simple thumbs up can go a long way!
It is common for people to step on each other when there’s an audio delay, and both parties are trying to communicate something. Don’t worry, just remember to try and pause before speaking, or consider raising your hand (if your video is on) to help the host determine who should speak first.

Thanks for making Kubernetes meetings work great!

Kubernetes Contributors – Communication Platform Guidelines and Policies

Docs: Calendar and Meeting Guidelines

Calendar Guidelines

Establishing a New Meeting

Testing Permissions

Transferring Ownership

Tips

Viewing Kubernetes Project Calendars

Adding Events to Your own Calendar

Calendar Event Template

Title

Description

Example

Troubleshooting

Permissions Impacted After Changing Positions or Role

Docs: Community Survey Requests

Requesting a Community Survey

What’s a Community Survey?

Survey Request Process

1. Determine Goals and Content of Survey

2. Request Survey Review

3. Request Survey Publication

4. Contributor Communications Promotion (optional)

5. Collect Survey Results

6. Publish Survey Results

Tips and Notes Around Surveys

Docs: Discuss Forum Guidelines

Discuss guidelines

Code of conduct

Privacy Policy

Admins

General communication guidelines

PM (Private Message) conversations

Escalating and/or reporting a problem

Moderation

Moderator expectations and guidelines

Other moderator responsibilities

Ingest queue

New category requests

Requesting a general category

Requesting a SIG, WG, or sub-project category

Requesting a regional category

Docs: Mailing List Guidelines

Mailing list guidelines

Code of conduct

Admins

Mailing list owners

Moderation

Moderator expectations and guidelines

New user posting queue

Annual permissions review

Mailing list creation

Prerequisites for creating a mailing list

Create the leads and members mailing lists

Set up shared calendars and meeting with a mailing list

Prerequisites for sharing a calendar and meeting notes

Sharing the calendar with the Google Group

Sharing the meeting notes with the Google Group

Archive a mailing list

Docs: Moderation Rules and Responsibilities

Moderation on Kubernetes Communications Channels

Selection of Moderators

Moderators Pro Tempore

Rotation of Moderators

Roles and Responsibilities

Violations

Escalation Procedures

Escalation to Code of Conduct Committee Procedures

Platform Specific Guidelines

Discuss

Mailing List

Slack

YouTube

Zoom

Process for Adding a Moderator

References and Resources

Docs: Moderator list

Community Moderators

Mailing Lists

kubernetes-dev