发布后沟通

Kubernetes 的发布沟通（Release Comms） 团队（隶属于 SIG Release） 负责管理发布相关的公告，这些公告会发布在主项目博客上。

每次发布之后，发布沟通团队会在一段时间内接管主博客，并发布一系列额外的文章， 用于解释或宣布与该版本相关的变更。这些额外的文章被称为发布后沟通（Post-release comms）。

参与发布后沟通

在一个发布周期中，作为贡献者，你可以选择参与关于 Kubernetes 即将发生的变更的发布后沟通。

要选择参与，你需要针对 k/website 提交一个草稿形式的占位拉取请求（PR）。 最初，这可以是一个空提交。在占位 PR 的描述中，请提及相关的 KEP（Kubernetes Enhancement Proposal） 问题或其他 Kubernetes 改进相关的问题。

当你提交草稿拉取请求时，需要以 main 作为基础分支， 而不是针对 dev-1.33 分支。 这与即将发布的变更和新功能的流程不同。

你还应在相关的 kubernetes/enhancements 问题下留下评论，并附上拉取请求的链接，以通知负责本次发布的发布沟通团队。 你的评论有助于团队了解该变更需要发布公告，并确认你的 SIG 已选择参与。

除此之外，理想情况下，你还应通过 Slack（频道 #release-comms） 联系发布沟通团队，告知他们你已完成上述操作并希望选择参与。

准备文章内容

你应该遵循常规的文章提交流程， 将你的占位 PR 转变为可供评审的内容。然而，对于发布后沟通， 你可能不会有一个写作伙伴；取而代之的是，发布沟通团队可能会指派一名成员来帮助指导你的工作。

你应该压缩拉取请求中的提交； 如果你不确定如何操作，完全可以向发布沟通团队或博客团队寻求帮助。

只要你的文章在前言中被标记为草稿（draft: true）， 该 PR 就可以在发布周期的任何时间合并。

发布

在实际发布之前，发布沟通团队会检查哪些内容已经准备就绪 （如果到了截止日期仍未准备好，且你没有获得豁免，那么公告将不会被收录）。 他们为即将发布的文章制定时间表，并开启新的拉取请求，将这些文章从草稿转为已发布。 以将这些文章从草稿状态变为已发布状态。

博客团队的批准者仍然需要对从草稿到可发布的内容提供最终的签字批准。 在发布日前，用于发布这些公告的拉取请求（PR）应已获得 LGTM（“我觉得不错”） 和批准标签，同时还需要添加 do-not-merge/hold 标签，以确保 PR 不会过早合并。

一旦实际发布完成并且网站 Git 仓库解冻，发布沟通团队或发布团队可以立即取消保留 PR（或一组 PR） PR（或一组 PR）的 hold 状态。

在每篇文章预定发布的当天，自动化流程将触发网站构建，该文章将会变成可见。