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 release-comms@kubernetes.io 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.
Throughout the release cycle, the main Communications deliverables include:
- Collection of Major Themes. The Communications team coordinates with SIG Leads to solicit Major Themes 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 Major Themes 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 Major Themes 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.
In the case of a low reponse rate in the Github discussion, each SIG should be pinged via their individual Slack channels and the #chairs-and-techleads channel.
The Communications team should hold a meeting to discuss Major Themes 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 major themes, 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 (e.g. Major Themes, User Highlights, Ecosystem Updates, etc.) and have the lead pull it all together and manage the PR and reviews.
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, and 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.
The first feature blog typically goes out on release day alongside or shortly after the release blog, and then are published one-at-a-time, typically at a rate of two to three posts weekly. The Comms team establishes the publication schedule.
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.
As feature blogs are opted in, assign them to shadows and yourself for tracking and facilitation. The responsibility is to ensure the blog authors have the resources and information they need, including editorial and tech reviews once ready.
Work closely with the SIG Docs Blogs team (Communicate with them via #sig-docs-blogs and by attending meetings), as they are typically available for editorial reviews. Share the feature blog schedule and updates with them throughout the cycle.
For tech reviews, reach out to authors and the sponsoring SIG to organize at least one tech review per blog post.
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. 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".
Work with SIG Contributor Experience (connecting on #sig-contribex and by attending meetings), to promote the feature blogs.
The suggested deadlines to be supported by the current Comms team:
- Deadline - PRs blog place holder: Week 09.
- Deadline - PRs ready for review: Week 11
Please note that the release team will support the blog publication after the release day too.
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 pr@cncf.io 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 pr@cncf.io
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 webinars@cncf.io. 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.
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".
| 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.