参与 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 在其中的运作方式有深入的了解。有关当前负责人列表，请参阅 Leadership。

SIG Docs 团队和自动化

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

GitHub 团队

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

@sig-docs-{language}-owners 是批准者和负责人
@sig-docs-{language}-reviews 是审查者

每个人都可以通过他们的 @name 在 GitHub 评论中提及，以便与该组中的每个人进行沟通。

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

OWNERS 文件和 front-matter

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

blunderbuss
批准

这两个插件使用 OWNERS 和 OWNERS_ALIASES 文件，位于 kubernetes/website GitHub 仓库的顶层目录中，以控制 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 文档的更多信息，请参阅