The Communications Coordinator role is responsible for facilitating, empowering, and curating communication between the release team and various stakeholders including the Cloud Native Computing Foundation (CNCF), the media, contributing vendors, Kubernetes project managers, and the overall Kubernetes community at large.
Communications deliverables that come from the release process include a release blog, an optional removals and deprecations blog, facilitation of a feature blog series, scheduling of a CNCF Kubernetes release webinar as well as other speaking opportunities, and approved messaging for media. In the event the release schedule slips, the communications coordinator will ensure media opportunities through the CNCF are synchronized and that all stakeholders are kept advised of changes in timing.
Before continuing on to the Communications specific requirements listed below, please review and work through the tasks in the Release Team Onboarding Guide.
- Strong written and verbal communications skills
- A working knowledge of Kubernetes concepts
- Fundamental GitHub skills and experience with open source projects
- Enough experience with the Kubernetes release process to understand how communications milestones fit into the overall release
- Project management experience
- Existing relationships with the CNCF, relevant media personnel and outlets, Kubernetes project managers, and vendor stakeholders is helpful, but not required
- The communications lead should take the Inclusive Speaker Orientation (LFC101) training course
The Kubernetes release cycle spans 15 weeks, however it may run longer. The typical workload for the communications team is very light during the first few weeks of the release cycle. In the later weeks, the workload can become heavy, and will continue a few weeks after the release.
The expected time investment for both leads and shadows are as follows:
-
30 minutes to 2 hours a day (depending upon week), requesting and reviewing incoming KEPs and blog PRs, working with other SIGs or the CNCF to manage the feature blog posts, and following Slack channels in order to keep pending content current.
-
1 to 5 hours a week, attending
- Release Team (weekly)
- SIG Docs Team (biweekly) and
- Burndown meetings (daily during Code Freeze).
NOTE: These are estimates and your personal experience may vary. The keys to success in this role are collaboration with the team and maintaining regular communication within the team.
Please use the [email protected] Google Group list for external release communications (communicating with the CNCF, etc.).
The following groups should be members:
- The current release cycle's Release Team Lead & Lead Shadows
- The current release cycle's Communications Lead & Comms Shadows
- SIG Release Chairs
The list must rotated/actively managed every cycle. Submit a PR to update this document per the milestone activities described below.
There is a channel on the Kubernetes Slack workspace, #release-comms, which is used by the communications release team to coordinate their efforts. If you're on the communications team, or applying to be, then it would be advantageous to follow along with the conversations. The Communications Coordinator (often referred to as the "Comms Lead") should post a status here at a regular cadence to keep release team members and other stakeholders informed.
How a particular team communicates day-to-day is up to the Comms Lead and teams members, but usually they Slack DM on day-to-day coordination and post summary updates in #release-comms.
Throughout the release cycle, the main Communications deliverables include:
- Collection of Release Highlights. The Communications team coordinates with SIG Leads to solicit Release Highlights for the release, to be used in both the Release Blog and Release Notes.
- Authoring the Kubernetes release blog. The Communications team writes the release blog, which is the official announcement of the Kubernetes release. This includes the Release Highlights from SIG leads.
- Coordination and support of the feature blog series. SIGs opt-in to author feature blogs for the release. These blogs are written by technical owners, and the Communications team supports authors from the early stages through facilitating editorial and tech reviews as well as publication.
- Coordination and support of an optional Deprecations and Removals blog. Depending upon the content of a given release, it may be necessary to prepare the community for upcoming deprecations and removals. This is decided per release cycle around the time of Code Freeze.
- Scheduling press activities and the post-release webinar with the CNCF. The Communications Coordinator works with the CNCF to schedule press release activities around the release, and to schedule the release webinar (typically scheduled 3-4 weeks post-release).
A GitHub Discussion must be open to invite all SIG leads and members to add Release Highlights for inclusion in the Release Blog and Release Notes. The discussion must be opened in kubernetes/sig-release under General Category.
Past discussions: 1.25, 1.24, 1.23, 1.22, 1.21.
Each SIG should be pinged via their individual Slack channels and the #chairs-and-techleads channel to solicit suggestions, and each KEP owner should be asked about inclusion as a Release Highlight at the same time Feature Blogs are being solicited.
The Communications team should hold a meeting to discuss Release Highlights sometime around Code Freeze. Ensure that at least one person from the Release Notes team attends this meeting with the Release Lead and Enhancements Lead.
The Communications Coordinator along with the Comms shadows are responsible for authoring the official Kubernetes Release blog. This blog is the official statement of release. The release blog is the primary vehicle by which the release team communicates the release highlights, known issues, and other aspects of the release to the community.
Start the draft with the team around week 12, striking a balance between the enhancements being close to finalized and having enough to time author the blog and have it reviewed. Ahead of review, open a pull request on the website repository and assign the release lead and other stakeholders as reviewers.
It's up to you and your team regarding how best to do this. Typically it works well to assign sections to different team members and have the lead pull it all together and manage the PR and reviews. You can work in a draft in Google Docs or Hackmd, then move into the PR when content is more finalized. Its also recommended to get KEP authors to provide 1-2 paragraph descriptions of KEP changes as a starting point for the release blog. This is an easier starting point for putting the whole release blog together.
The release lead will drive the content for the release theme and logo.
Tracking, facilitating, and organizing the publication of the Feature Blog series is a major deliverable of the Comms team. Feature blogs are opt-in for SIGs, and are authored by enhancement developers and others close to the features. We do, however, need to encourage owners of important enhancements to opt in to writing feature blogs.
Examples of enhancements that warrant a feature blog might include:
- breaking changes
- features and changes important to our users
- features that have been in progress for a long time and are graduating
- features that are considered mandatory by the Release Lead.
It helps to work closely with the Release Lead and use the respective SIG Slack channels to remind the SIGs about opting in to feature blogs and provide any necessary context to blog authors.
Reach out in KEP issues to ask for feature blog opt-in. Ask every KEP owner if they want to contribute a blog by reaching out in the KEP issue. Example messaging is below.
👋 from the v1.31 Communications Team!
We'd love for you to consider writing a feature blog about your enhancement! Some reasons why you might want to write a blog for this feature include (but are not limited to) if this introduces breaking changes, is important to our users, or has been in progress for a long time and is graduating.
To opt-in, let us know and open a Feature Blog placeholder PR against the [website repository](https://github.com/kubernetes/website) by **[BLOG PLACEHOLDER PR DEADLINE]**. For more information about writing a blog see the [blog contribution guidelines](https://kubernetes.io/docs/contribute/new-content/blogs-case-studies/#technical-considerations-for-submitting-a-blog-post).
Note: In your placeholder PR, use `XX` characters for the blog `date` in the front matter and file name. We will work with you on updating the PR with the publication date once we have a final number of feature blogs for this release.
NOT EVERY KEP NEEDS A BLOG. Work with the KEP owners, Release Lead, and SIG Docs Blog team (though #sig-dcos-blog slack channel) to make sure all KEPs that opt-in really need a blog written. If a feature is small, or new in Alpha it may not be ready for a blog. You should also encourage important features to sign up to write a blog.
As feature blogs are opted in and placeholder PRs are created, assign the blogs to shadows and yourself for tracking and facilitation. The Comms team is responsible for making sure blog authors have the resources and information they need to write the blog, and tracking the blogs progress through editorial and tech reviews once the blog is ready. After a blog placeholder PR has been created, you should swtich to using the placeholder PR for contacting authors on GitHub instead of the KEP issue.
Some features that opt-in to writing a blog may miss the code freeze deadline. Blog placeholder PRs for features that are no longer in the release should be closed.
When a placeholder PR is created, make sure the PR has been held using the /hold command. Feature blogs should not be merged until after the release date and the comms team has assigned a publication date.
Anyone can hold a PR by adding a comment with the /hold command, like the example below. This will to apply the do-not-merge/hold label to the PR and will prevent the PR from merging until the label is removed. This will stop a blog from accidently merging and publishing ahead of the release. 1.31 Example.
/hold
Pending assignment of publication date by release comms. This blog should be held until the vX.XX release has happened.
Once the release has happened, use the /unhold command to remove the do-not-merge/hold.
The Comms team establishes the feature blog publication schedule. Other members of the release team or blog reviewers may contribute ideas and feedback on the schedule, but ultimately the schedule is determined by the Comms team.
Use the blog schedule field in the Feature Blog view on the tracking board to assign a publication date.
Feature blog publication usually starts the day after the release. The release blog goes out on same day as the release and the first feature blog typically goes out the day after the release. The rest of the blogs are published one-at-a-time, typically at a rate of two to three posts weekly. Depending on how many feature blogs you have, you may want to publish one per day after the release (excluding weekends). In general, all feature blogs should be published within month of the release day.
Note that blog PRs in k/website are dated, and automation will publish future-dated entries. This enables a PR process decoupled from blog publication date. Once a blog has passed the review process and its after the release day, the PR can be merged and will be published on the date on the blog.
Communicate the planned publish date to SIG Docs and the owner of the feature blog. Notify the author in the PR and Slack channels: #sig-docs-blog, #sig-docs about the schedule. The communications team will assist in coordinating and publishing the feature blogs on schedule.
See example here, "this article is scheduled for the 21th of August".
Please note that the release team will support the blog publication after the release day too.
Also see the docs for pull requests review process and reviewing a pull request.
Work closely with the SIG Docs Blogs team. These are the folks responsible for editorial reviews (and sometimes tech reviews) of Kubernetes blogs. The Comms lead should plan to regularly share updates on blog status and review timelines with the blog reviewers via #sig-docs-blogs and during sig-docs meetings.
Each blog should pass 2 official reviews, an editorial review and tech review. Anyone is open to do an "informal" review on any blog and leave suggestions. As part of the comms team, it's encouraged (but not required) to help reviews blogs for both editorial and technical correctness if you have time.
An official review comes from someone with permission to add the lgtm label to a pull request.
- Tech reviews usually come from the sponsoring SIG. If you dont see a tech review on the blog, reach out to the author to make sure the PR has been flagged for review. You can also reach out in the SIG slack channel to ask for help with tech reviews.
- Editorial reveiws usually come from blog reviewers or SIG Docs reviewers. They make sure that the blog is readable and adheres to the style guide. You can also reach out to the SIG Docs PR wrangler, for help getting reviews or approvals on PRs. See the PR wrangler schedule for more details.
Once a blog has the lgtm label assigned an [approver] can add the aprove label to get the PR merged. Note that reviews can still happen on blogs with a lgtm label.
Aim to have all blogs reviewed and approved by release day. But note that its common for blog reviews to continue past the release day.
Throughout the release cycle the comms team works with lots of different teams within the Kubernetes community. As a Comms lead or member of the comms team, you should feel empowered to reach out and ask questions or as for help from SIGs and other Release team members to meet deadlines.
Some groups you may need to contact include
- SIG Contributor Experience in the
#sig-contribexslack channel and by attending meetings. They can help promote the feature blogs through social media. Also see the spcial posts section below. - Chairs and Tech Leads of SIGs in the
#chairs-and-techleadsslcak channel. This can be a helpful place to post reminders about blog deadlines SIG leads to see.
This blog is OPTIONAL and will vary from release to release. Work with the rest of the release team ahead of the Code Freeze date to determine if a mid-cycle blog focused on feature deprecations and removals is warranted.
If so, facilitate its creation and publication. You can create a Slack thread on #sig-release and #sig-docs-blog to discuss this.
If the release will deprecate important and commonly-used features (or simply a large number of features will be deprecated), consider publishing this blog.
Also consider this when commonly-used features that have been deprecated are removed in a release. Follow these examples:
- Kubernetes API and Feature Removals in 1.22
- Deprecated APIs Removed in 1.16
- Kubernetes Removals and Major Changes In 1.25
Publication should occur ahead of the release in order to inform the community and allow for preparation time. Start the discussion mid-cycle and well ahead of Code Freeze, and target publication for Code Freeze week.
This is a simple but very important component of the Communications Coordinator role. Two sets of activities need to be scheduled with the CNCF:
- press release and interview scheduling around the release day and
- the release webinar after the release.
You will be a liaison between the Release lead and the CNCF contacts to schedule the press briefings. Send an email to [email protected] about a month ahead of the release and coordinate between the parties to get release day press events scheduled.
See the sample email for schedule press and pre-briefings for the release lead with CNCF by emailing [email protected]
CC'd release-comms and the release lead.
Title: Schedule interview for the release lead
Hi there,
I'm the comms lead for Kubernetes v1.xx (currently scheduled to release Tuesday 5th December 20xx), and I'm reaching out to get our release day and pre-release press handled.
Thanks,
Communication Team 1.xx
To schedule the release webinar with the CNCF, start things with an email to [email protected]. You will likely use the Calendly link (below) to schedule a "live webinar". If things are tight on the schedule, CNCF will help find a spot.
The webinar is typically scheduled for 3-4 weeks after the release and is primarily presented by the Release lead and Enhancements lead. Often the Comms lead will also join the webinar. The format is open, but primarily the team walks through the enhancements in the release and gives a sneak peek of what's coming in the next release.
See the sample webinar email below for reference.
title: Scheduling the Kubernetes 1.xx Release Live Webinar
Hi there! I'm the communication lead for Kubernetes v1.xx, XXXX, and I'm reaching out to schedule a live webinar for our release and enhancements leads. Could you help us to schedule in the Calendly: https://calendly.com/cncfonlineprograms/livewebinar
This version is currently scheduled to land Tuesday 5th December 20xx, see the details here: https://www.kubernetes.dev/resources/release/
Do you have availability sometime for 3-4 weeks after the release, maybe between x-x in December?
Thanks,
Comms Team 1.xx
Refer to the slides and webinar from the 1.22 release as an example.
Note you'll need to send headshots and company/title information when you schedule the webinar and the slides should be sent for CNCF review at least one week ahead of the webinar.
The Release Communications team is NOT responsible for social posting. SIG Contributor Experience (SIG Contribex) manages the official Kubernetes social accounts and is responsible for all posts to those accounts. SIG Contribex has created automation around blog posts, so once a blog is published to the Kubernetes website, social posts are created and posted according to SIG Contribex's automation schedule.
If the Communications team and Release Lead determine a feature or other release communication needs a more detailed communications or calls to action, reach out to with SIG Contributor Experience for help making posts use the @contributor-comms tag in the #sig-contribex Slack channel.
Try to give 2 weeks notice for all deadlines and requests for reviews. When planning to reach out for blog opt-in or asking for reviews on blog drafts, you should start posting messages or have blog drafts ready for review at least two weeks from the deadline. Especially when asking for blog reviews, as the blog team is understaffed, this will give reviewers enough time to do the review and you enough time to address any feedback. This is best effort guideline, as the schedule does not always allow for this much lead time before a deadline.
Post messages to GitHub or in SIG slack channels for the best visibility into ongoing work and to allow other contributors to help. Having messages in the KEPs, blog PRs, or SIG slack channels, can help centralize information about the work being done and any outstanding issues. If you need to escalate an issues to Release Leads or SIG Chairs, having public messages/records of conversations can make it easy to tag who you need to.
If you do use direct messages to contact someone during a release, post summaries of the conversation to PRs or SIG slack channels. This way everyone can stay up-to-date on the ongoing work.
As much as possible stick to the comms deadlines set in the release schedule for the mid-cycle blog and main release blog. This will ensure that no release-blocking issues come up and that all blogs go out when they need to.
Feature blog deadlines are a little more flexible compared to other release deadlines. Because the feature blogs are published after the release, there is usually more wiggle room on the deadlines. In general, as long as blog authors are responsive and blog content is getting added/reviewed, its OK to give authors extra time to finish their work. If you need to, you can publish the blog later in the publicaiton schedule to give the author and reviewers more time to complete the blog. If you feel that a blog author is not responsive, progress is not being made, and the dealines have been stretched too far, escalate to the release or SIG chairs or cancel the blog. A blog can always been written outside of the release cycle.
This is an example of a typical release cycle and the order of how tasks will flow for Comms. Note that some tasks may take longer than their designated "release week". Each release is a little different, the following guideline is only a suggestion. You should always refer to the specific release schedule for exact dates and deadlines in a release cycle.
| 1 | Start of release cycle |
|
| 2 |
|
|
| 3 | Production Readiness Freeze |
|
| 4 | Enhancements Freeze |
|
| 5 |
|
|
| 8 |
|
|
| 10 |
|
|
| 11 | Feature blog freeze |
|
| 12 | Code Freeze |
|
| 13 |
|
|
| 14 | Feature Blogs ready to review |
|
| 15 | Release Week |
|
| 16 | Release retrospective |
|
To support you in the creation of the release blog this outline summarize ideas for sections and gives you a template for easier release blog creation.