参与 SIG Docs

    SIG Docs 欢迎所有贡献者提供内容和审阅。任何人可以提交拉取请求（PR）。 欢迎所有人对文档内容创建 Issue 和对正在处理中的 PR 进行评论。

    你也可以成为成员（member）、 或者 批准人（approver）。 这些角色拥有更高的权限，且需要承担批准和提交变更的责任。 有关 Kubernetes 社区中的成员如何工作的更多信息，请参见 。

    本文档的其余部分概述了这些角色在 SIG Docs 中发挥作用的一些独特方式。 SIG Docs 负责维护 Kubernetes 最面向公众的方面之一 —— Kubernetes 网站和文档。

    每个 SIG，包括 SIG Docs，都会选出一位或多位成员作为主席。 主席会成为 SIG Docs 和其他 Kubernetes 组织的联络接口人。 他们需要了解整个 Kubernetes 项目的架构，并明白 SIG Docs 如何在其中运作。 如需查询当前的主席名单，请查阅 。

    GitHub 上有两类 SIG Docs 团队：

    • 包含批准人和牵头人
    • @sig-docs-{language}-reviews 包含评阅人

    可以在 GitHub 的评论中使用团队的名称 @name 来与团队成员沟通。

    有时候 Prow 所定义的团队和 GitHub 团队有所重叠，并不完全一致。 对于指派 Issue、PR 和批准 PR，自动化工具使用来自 OWNERS 文件的信息。

    OWNERS 文件和扉页

    Kubernetes 项目使用名为 prow 的自动化工具来自动处理 GitHub issue 和 PR。 使用了两个 prow 插件：

    • blunderbuss

    OWNERS 文件包含 SIG Docs 评阅人和批准人的列表。 OWNERS 文件也可以存在于子目录中，可以在子目录层级重新设置哪些人可以作为评阅人和 批准人，并将这一设定传递到下层子目录。 关于 OWNERS 的更多信息，请参考 文档。

    此外，每个独立的 Markdown 文件都可以在其前言部分列出评阅人和批准人， 每一项可以是 GitHub 用户名，也可以是 GitHub 组名。

    结合 OWNERS 文件及 Markdown 文件的前言信息，自动化系统可以给 PR 作者可以就应该 向谁请求技术和文字评阅给出建议。

    当某个拉取请求（PR）被合并到用来发布内容的分支，对应的内容就会被发布到 。 为了确保我们所发布的内容的质量足够好，合并 PR 的权限仅限于 SIG Docs 批准人。下面是合并的工作机制：

    • 当某个 PR 同时具有 lgtm 和 approve 标签，没有 hold 标签且通过所有测试时， 该 PR 会被自动合并。
    • Kubernetes 组织的成员和 SIG Docs 批准人可以添加评论以阻止给定 PR 的自动合并， 即通过 评论或者收回某个 /lgtm 评论实现这点。
    • 所有 Kubernetes 成员可以通过 /lgtm 评论添加 lgtm 标签。
    • 只有 SIG Docs 批准人可以通过评论 合并 PR。 某些批准人还会执行一些其他角色，例如 PR 管理者 或 等。
    角色与责任
    PR 管理者