Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 6 additions & 3 deletions release-team/role-handbooks/communications/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -59,7 +59,7 @@ Throughout the release cycle, the comms team works with lots of different teams

Some groups you may need to contact, on top of the already mentioned SIG Docs (Blog), include:

* SIG Contributor Experience in the `#sig-contribex` slack channel and by attending meetings. They can help promote the feature blogs through social media. Also, see the special posts section below.
* SIG Contributor Experience in the `#sig-contribex` or `#sig-contribex-comms` slack channel and by attending meetings. They can help promote the feature blogs through social media. Also, see the special posts section below.
* Chairs and Tech Leads of SIGs in the `#chairs-and-techleads` Slack channel. This can be a helpful place to post reminders about blog deadlines SIG leads to see.

## Release deliverables
Expand Down Expand Up @@ -128,7 +128,10 @@ Examples of enhancements that warrant a feature blog might include:
* 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.
There have been instances where blogs covering breaking changes for a future release have to be published.
There are two options for blogs covering breaking changes. They can be published as a regular feature blog (post-release communication) with the standard front matter. Alternatively, if the blog needs to go out before the release announcement, it can be published without the version prefix in the front matter and then linked in the release notes or announcement blog post.

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 can be found [here](/release-team/role-handbooks/communications/templates/feature-blog-opt-in-message.md).

Expand Down Expand Up @@ -259,7 +262,7 @@ See this file for some [tips and tricks](/release-team/role-handbooks/communicat

The Release Communications team is **NOT** responsible for social posting. [SIG Contributor Experience](https://github.com/kubernetes/community/tree/master/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.
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` or `#sig-contribex-comms` Slack channel.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really like the direction of this, it's been a long-standing goal to have better integration between Comms and Contribex Comms. My only doubt here is the use of "or"... not that I have a great answer, but if I do not know either channels, I'm likely to be confused - should I use both? Just the first? Why?

Perhaps something like "#sig-contribex (the SIG main channel) or #sig-contribex-comms (the Comms subproject channel, more directly responsible for blogging and social media)", although this doesn't answer the hypothetical question I just made...

Perhaps:

"Either channels are adequate: as a guideline, you can start in #sig-contribex and then the conversation might follow up in #sig-contribex-comms".

@jberkus @kaslin , WDYT?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason why I used this phrasing was because the doc only mentioned the contribex channel, but there are technically two channels to have the conversation in.


## Release Milestone Activities

Expand Down