为版本特性撰写文档
每次 Kubernetes 主要版本发布都会引入需要文档的新功能。新版本还会带来现有功能和文档的更新（例如，将功能从 Alpha 升级到 Beta）。
通常，负责某功能的 SIG 会将其功能的草稿文档通过 pull request 提交到 `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 问题的链接、其稳定级别（Alpha、Beta 或 Stable）、负责实现它的 SIG 和个人、是否需要文档、功能的发布说明草稿以及是否已合并。请牢记以下几点：
- Beta 和 Stable 功能通常比 Alpha 功能具有更高的文档优先级。
- 很难测试（因此也难以编写文档）一个尚未合并的功能，或者至少在 PR 中被认为是功能完整的）。
- 确定一个功能是否需要文档是一个手动过程。即使功能未标记为需要文档，您也可能需要为其编写文档。
面向开发者或其他 SIG 成员
本节提供有关 Kubernetes 其他 SIG 成员为发布编写新功能文档的信息。
如果您是为 Kubernetes 开发新功能的 SIG 成员，您需要与 SIG Docs 合作，以确保您的功能在发布前及时完成文档编写。查看 功能跟踪电子表格 或在 `#sig-release` Kubernetes Slack 频道中查询，以验证计划详情和截止日期。
打开占位符 PR
- 在 `kubernetes/website` 仓库的 `dev-1.35` 分支上打开一个 **草稿** pull request，包含一个稍后会修改的小提交。要创建草稿 pull request，请使用 **Create Pull Request** 下拉菜单，选择 **Create Draft Pull Request**，然后点击 **Draft Pull Request**。
- 编辑 pull request 描述，加入指向 kubernetes/kubernetes PR(s) 和 kubernetes/enhancements issue(s) 的链接。
- 在相关的 kubernetes/enhancements issue 上留下一条评论，附上 PR 的链接，以通知负责此版本文档的人员，功能文档即将到来，应被跟踪以用于发布。
如果您的功能不需要任何文档更改，请在 `#sig-release` Slack 频道中提及，以告知 sig-release 团队。如果功能需要文档但 PR 未创建，该功能可能会从里程碑中移除。
PR 已准备好进行审核
准备就绪后，用功能文档填充您的占位符 PR，并将 PR 的状态从草稿更改为 **准备审核**。要将 pull request 标记为准备审核，请导航至合并框并点击 **Ready for review**。
尽力描述您的功能以及如何使用它。如果您在组织文档方面需要帮助，请在 `#sig-docs` Slack 频道中提问。
完成内容后，分配给您功能的文档人员会进行审核。为确保技术准确性，内容可能还需要相应 SIG 的技术审核。根据他们的建议，使内容达到发布就绪状态。
如果您的功能需要文档但未收到初稿内容，该功能可能会从里程碑中移除。
功能门控
如果您的功能是 Alpha 或 Beta 功能，并且受功能门控 (feature gate) 的约束，您需要在 `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 将完全不再包含该功能门控。要表示功能门控已被移除，请在相应描述文件的 front matter 中包含 `removed: true`。进行此更改意味着功能门控信息将从 已毕业或已弃用功能的功能门控 部分移至一个名为 功能门控 (已移除) 的专用页面，包括其描述。
所有 PR 都已审核并准备好合并
如果您的 PR 在发布截止日期前尚未合并到 `dev-1.35` 分支，请与负责该版本文档的人员合作，确保在截止日期前完成。如果您的功能需要文档但文档尚未准备好，该功能可能会从里程碑中移除。