为发行版本撰写功能特性文档

    通常，负责某功能特性的 SIG 要为功能特性的文档草拟文档，并针对 仓库的合适的开发分支发起拉取请求。 SIG Docs 团队会提供文字方面的反馈意见，或者直接编辑文档草稿。 本节讨论两个小组在分支方面和发行期间所遵从的流程方面的约定。

    一般而言，文档贡献者不会为某个发行版本从头撰写文档。 相反，他们会与开发该功能特性的 SIG 团队一起，对文档草稿进行润色， 使之符合发布条件。

    在你选定了某个功能特性，为其撰写文档（主笔或辅助），请在 #sig-docs Slack 频道、SIG Docs 的每周例会上， 或者在功能特性对应的 PR 上提出咨询。 如果继续工作是没有问题的，你可以使用 中描述的技术之一，参与 PR 的编辑工作。

    要了解即将发布的功能特性，可以参加每周的 SIG Release 例会 （参考社区页面，了解即将召开的会议）， 监视 中与发行相关的文档。 每个发行版本在 /sig-release/tree/master/releases/ 下都有一个对应的子目录。 该子目录包含了发行版本的时间计划、发行公告的草稿以及列举发行团队名单的文档。

    发行时间计划文件中包含到所有其他文档、会议、会议记录及发行相关的里程碑的链接。 其中也包含关于发行版本的目标列表、时间线，以及当前发行版本中就绪的特殊流程的信息。 文档末尾附近定义了若干与该发行版本有关的术语。

    发行团队文档列举了哪些人扮演着各个发行版本的不同角色。 如果不清楚要联系谁来讨论特定的功能特性或者回答你的问题， 你可以参加发行团队的会议，提出你的问题，或者联系发行团队的牵头人， 这样他们就可以帮你找到正确的联系人。

    发行说明草稿是用来发现与特定发行版本相关的功能特性、变更、废弃以及其他信息的好来源。 由于在发行周期的后段该文档的内容才会最终定稿，参考其中的信息时请谨慎。

    针对 特性跟踪清单中列举的是计划包含于该版本中的每个功能特性。 每一行中都包含特性的名称、特性对应的主要 GitHub Issue，其稳定性级别（ALpha、 Beta 或 Stable）、负责实现该特性的 SIG 和个人、是否该特性需要文档、该特性的 发行说明草稿以及该特性是否已经被合并等等。阅读此清单时请注意：

    • 如果某功能特性尚未被合并，就很难测试或者为其撰写文档。 对于对应的 PR 而言，也很难讲特性是否完全实现。
    • 确定某个功能特性是否需要对应的文档的过程是一个手动的过程。 即使某个功能特性没有标记需要文档，并不意味着该功能真的不需要任何文档。

    针对开发人员或其他 SIG 成员

    本节中的信息是针对为发行版本中新功能特性撰写文档的来自其他 Kubernetes SIGs 的成员。

    如果你是某个 SIG 的成员，负责为 Kubernetes 开发某一项新的功能特性，你需要与 SIG Docs 一起工作，确保这一新功能在发行之前已经为之撰写文档。 请参考特性跟踪清单 或者 Kubernetes Slack 上的 #sig-release 频道，检查时间安排的细节以及截止日期。

    1. 在 仓库上针对 dev-1.21 分支提交一个 PR，其中包含较少的、待以后慢慢补齐的提交内容。
    2. 使用 Prow 命令 /milestone 1.21 将 PR指派到对应的里程碑。这样做会提醒负责管理对应发行版本的文档团队成员，有 新的功能特性要合并到将来版本。

    时机成熟时，你可以在你的占位 PR 中完成功能特性文档。

    尽可能为功能特性提供详尽文档以及使用说明。如果你需要文档组织方面的帮助，请 在 #sig-docs Slack 频道中提问。

    当你已经完成内容撰写，指派给你的功能特性的文档贡献者会去评阅文档。 为了确保技术准确性，内容可能还需要相应 SIG 的技术审核。 尽量利用他们所给出的建议，改进文档内容以达到发布就绪状态。

    如果你的功能特性需要文档，而一直没有关于该特性的文档提交评阅， 该特性可能会被从里程碑中移除。

    如果你的 PR 在发行截止日期之前尚未合并到 dev-1.21 分支， 请与负责管理该发行版本的文档团队成员一起合作，在截止期限之前将其合并。 如果功能特性需要文档，而文档并未就绪，该特性可能会被从里程碑中去除。