为版本发布撰写功能特性文档
每个主要的 Kubernetes 版本都会引入需要文档的新功能特性。新版本还会带来现有功能特性和文档的更新（例如将功能特性从 alpha 升级到 beta）。
通常，负责某个功能特性的 SIG 会将该功能特性的文档草案作为拉取请求提交到 kubernetes/website 仓库的相应开发分支，SIG Docs 团队成员会提供编辑反馈或直接编辑草案。本节介绍发布过程中这两个组所使用的分支约定和流程。
要了解如何在博客上宣布功能特性，请阅读发布后沟通。
文档贡献者须知
通常，文档贡献者不会从头开始为一个版本撰写内容。相反，他们与创建新功能特性的 SIG 合作，优化文档草案，使其达到发布就绪状态。
在你选择了要撰写或协助撰写文档的功能特性后，可以在 #sig-docs Slack 频道、每周的 SIG Docs 会议上或直接在功能特性 SIG 提交的 PR 上询问相关信息。如果获得批准，可以使用提交到他人 PR 中所述的技术之一编辑 PR。
了解即将发布的功能特性
要了解即将发布的功能特性，请参加每周的 SIG Release 会议（请参阅社区页面了解即将举行的会议），并关注 kubernetes/sig-release 仓库中特定于版本的文档。每个版本在 /sig-release/tree/master/releases/ 目录中都有一个子目录。该子目录包含发布计划、发布说明草案以及列出发布团队每个成员的文档。
发布计划包含所有与版本发布相关的其他文档、会议、会议记录和里程碑的链接。它还包含有关版本目标的发布时间表，以及该版本中采取的任何特殊流程。文档底部附近定义了几个与发布相关的术语。
本文档还包含指向功能特性跟踪表的链接，这是了解所有计划进入该版本的新功能特性的官方方式。
发布团队文档列出了负责每个发布角色的成员。如果你不清楚针对某个特定功能特性或问题应该与谁交流，可以参加发布会议提出你的问题，或者联系发布负责人，以便他们为你指明方向。
发布说明草案是了解特定功能特性、变更、弃用以及更多关于版本发布信息的良好途径。内容在发布周期的后期才会最终确定，因此请谨慎使用。
功能特性跟踪表
指定 Kubernetes 版本的功能特性跟踪表列出了计划在某个版本中包含的每个功能特性。每个条目包含功能特性名称、指向该功能特性主要 GitHub Issue 的链接、其稳定性级别（Alpha、Beta 或 Stable）、负责实现的 SIG 和个人、是否需要文档、功能特性发布说明草案以及是否已合并。请记住以下几点：
- Beta 和 Stable 功能特性的文档优先级通常高于 Alpha 功能特性。
- 对于尚未合并或至少在其 PR 中被认为功能已完成的功能特性，很难对其进行测试（因此也难以撰写文档）。
- 判断一个功能特性是否需要文档是一个手动过程。即使一个功能特性没有被标记为需要文档，你可能仍然需要为其撰写文档。
面向开发者或其他 SIG 成员
本节面向负责为版本发布撰写新功能特性文档的其他 Kubernetes SIG 成员。
如果你是开发 Kubernetes 新功能特性的 SIG 成员，你需要与 SIG Docs 合作，确保你的功能特性文档及时准备好以便发布。请查阅功能特性跟踪电子表格或在 #sig-release Kubernetes Slack 频道中确认调度详情和截止日期。
发起占位 PR
- 针对
kubernetes/website仓库中的dev-1.34分支发起一个草稿拉取请求，其中包含一个小提交，稍后你将对其进行修改。要创建草稿拉取请求，请使用创建拉取请求下拉菜单，选择创建草稿拉取请求，然后点击草稿拉取请求。 - 编辑拉取请求描述，包含指向 kubernetes/kubernetes PR 和 kubernetes/enhancements Issue 的链接。
- 在相关的 kubernetes/enhancements Issue 上留下一个包含该 PR 链接的评论，通知负责该版本发布的文档人员功能特性文档即将提交，并且应跟踪其是否包含在该版本中。
如果你的功能特性不需要任何文档变更，请确保 sig-release 团队知晓这一点，可以在 #sig-release Slack 频道中提及。如果功能特性需要文档但 PR 未创建，该功能特性可能会从里程碑中移除。
PR 准备评审
准备就绪后，在你的占位 PR 中填充功能特性文档，并将 PR 的状态从草稿改为准备评审。要将拉取请求标记为准备评审，请导航到合并框并点击准备评审。
尽力描述你的功能特性以及如何使用它。如果你在文档结构方面需要帮助，请在 #sig-docs Slack 频道中提问。
当你完成内容后，分配给你的功能特性的文档人员会对其进行评审。为了确保技术准确性，内容可能还需要相应 SIG 的技术评审。根据他们的建议使内容达到发布就绪状态。
如果你的功能特性需要文档并且未收到第一份草稿内容，该功能特性可能会从里程碑中移除。
特性门控
如果你的功能特性是一个 Alpha 或 Beta 功能特性，并且受特性门控控制，你需要在 content/en/docs/reference/command-line-tools-reference/feature-gates/ 目录下为其创建一个特性门控文件。文件名应为特性门控的名称，后缀为 .md。你可以参考同一目录下的其他文件了解你的文件应该是什么样子。通常一段即可；对于更长的解释，请在其他地方添加文档并链接到该处。
此外，为确保你的特性门控出现在Alpha/Beta 特性门控表中，请在你的 Markdown 描述文件的前置信息 (front matter) 中包含以下详细信息：
stages:
- stage: <alpha/beta/stable/deprecated> # Specify the development stage of the feature gate
defaultValue: <true or false> # Set to true if enabled by default, false otherwise
fromVersion: <Version> # Version from which the feature gate is available
toVersion: <Version> # (Optional) The version until which the feature gate is available
对于全新的特性门控，还需要单独的特性门控描述；在 content/en/docs/reference/command-line-tools-reference/feature-gates/ 目录下创建一个新的 Markdown 文件（可以使用其他文件作为模板）。
当你将一个特性门控从默认禁用更改为默认启用时，你可能还需要更改其他文档（而不仅仅是特性门控列表）。请注意类似以下的表述：“exampleSetting 字段是一个 beta 字段，默认禁用。你可以通过启用 ProcessExampleThings 特性门控来启用它。”
如果你的功能特性已 GA（正式发布）或已弃用，请在描述文件中的 stages 块内包含一个额外的 stage 条目。确保 Alpha 和 Beta 阶段保持不变。此步骤将特性门控从Alpha/Beta 特性门控表迁移到已毕业或已弃用功能特性门控表。例如：
stages:
- stage: alpha
defaultValue: false
fromVersion: "1.12"
toVersion: "1.12"
- stage: beta
defaultValue: true
fromVersion: "1.13"
# Added a `toVersion` to the previous stage.
toVersion: "1.18"
# Added 'stable' stage block to existing stages.
- stage: stable
defaultValue: true
fromVersion: "1.19"
toVersion: "1.27"最终，Kubernetes 将完全停止包含该特性门控。要表示移除某个特性门控，请在相应描述文件的前置信息中包含 removed: true。进行此更改意味着特性门控信息将从已毕业或已弃用功能特性门控部分移至一个名为特性门控（已移除）的专用页面，其中包括其描述。
所有 PR 均已评审并准备好合并
如果你的 PR 在发布截止日期前尚未合并到 dev-1.34 分支，请与负责该版本发布的文档人员合作，确保在截止日期前完成合并。如果你的功能特性需要文档而文档尚未准备好，该功能特性可能会从里程碑中移除。