参与 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 评论中用其 @name 进行引用，以便与该组中的所有人进行交流。

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

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

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

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

此外，单个 Markdown 文件可以在其前置信息中列出审阅者和批准者，方法是列出单个 GitHub 用户名或 GitHub 组。

OWNERS 文件和 Markdown 文件中的前置信息的组合决定了 PR 所有者从自动化系统获得的关于向谁请求技术和编辑审查的建议。

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

当一个拉取请求同时具有 lgtm 和 approve 标签，并且没有 hold 标签，并且所有测试都通过时，该拉取请求将自动合并。
Kubernetes 组织成员和 SIG Docs 批准者可以添加评论以阻止特定拉取请求的自动合并（通过添加 /hold 评论或保留 /lgtm 评论）。
任何 Kubernetes 成员都可以通过添加 /lgtm 评论来添加 lgtm 标签。
只有 SIG Docs 批准者可以通过添加 /approve 评论来合并拉取请求。一些批准者还执行其他特定角色，例如 PR 处理者或 SIG Docs 主席。

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