参与 SIG Docs

SIG Docs 是 Kubernetes 项目中的一个特别兴趣小组，专注于为整个 Kubernetes 编写、更新和维护文档。有关该 SIG 的更多信息，请参阅社区 GitHub 仓库中的 SIG Docs。

SIG Docs 欢迎所有贡献者提供内容和审阅。任何人都可以提交一个拉取请求 (PR)，并且欢迎任何人针对内容提交问题或评论正在进行的拉取请求。

您还可以成为成员、审阅者或批准者。这些角色需要更高的访问权限，并承担批准和提交更改的某些责任。有关成员身份在 Kubernetes 社区中如何运作的更多信息，请参阅community-membership。

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

SIG Docs 主席

每个 SIG（包括 SIG Docs）都会选择一名或多名 SIG 成员担任主席。他们是 SIG Docs 与 Kubernetes 组织其他部门之间的联系点。他们需要对整个 Kubernetes 项目的结构以及 SIG Docs 在其中如何运作有广泛的了解。有关当前主席列表，请参阅领导层。

SIG Docs 中的自动化依赖于两种不同的机制：GitHub 团队和 OWNERS 文件。

在 GitHub 上，SIG Docs 有两个类别的团队：

在 GitHub 评论中，可以通过 @名称 来引用它们，以与该组中的所有人进行交流。

有时 Prow 和 GitHub 团队会重叠但不完全匹配。对于问题的分配、拉取请求以及支持 PR 批准，自动化使用来自 OWNERS 文件中的信息。

Kubernetes 项目使用一个名为 prow 的自动化工具来处理与 GitHub 问题和拉取请求相关的自动化。 the Kubernetes 网站存储库使用两个 prow 插件：

这两个插件使用 kubernetes/website GitHub 存储库顶级的 OWNERS 和 OWNERS_ALIASES 文件来控制 prow 在该存储库中的工作方式。

OWNERS 文件包含 SIG Docs 审阅者和批准者列表。OWNERS 文件也可以存在于子目录中，并可以覆盖该子目录及其后代文件中谁可以作为审阅者或批准者。有关 OWNERS 文件的一般信息，请参阅 OWNERS。

此外，单个 Markdown 文件可以在其 front-matter 中列出审阅者和批准者，可以通过列出单个 GitHub 用户名或 GitHub 组来实现。

OWNERS 文件和 Markdown 文件中的 front-matter 的组合决定了 PR 所有者从自动化系统那里获得哪些关于向谁寻求 PR 的技术和编辑审阅的建议。

当一个拉取请求被合并到用于发布内容的分支时，该内容就会发布到 https://kubernetes.ac.cn。为了确保我们发布内容的质量很高，我们限制了拉取请求的合并权限给 SIG Docs 批准者。工作原理如下：

当一个拉取请求同时具有 lgtm 和 approve 标签，没有 hold 标签，并且所有测试都通过时，该拉取请求将自动合并。
Kubernetes 组织成员和 SIG Docs 批准者可以通过添加 /hold 注释来阻止给定拉取请求的自动合并（或者不添加 /lgtm 注释）。
任何 Kubernetes 成员都可以通过添加 /lgtm 注释来添加 lgtm 标签。
只有 SIG Docs 批准者可以通过添加 /approve 注释来合并拉取请求。一些批准者还承担额外的特定角色，例如 PR Wrangler 或 SIG Docs 主席。

有关为 Kubernetes 文档做出贡献的更多信息，请参阅：