website/content/zh/docs/contribute/advanced.md

title, slug, content_template, weight

title	slug	content_template	weight
高级贡献	advanced	templates/concept	30

{{% capture overview %}}

如果你已经阅读并掌握开始贡献和中级贡献，并准备了解更多贡献的途径，请阅读此文。您需要使用 Git 命令行工具和其他工具做这些工作。

{{% /capture %}}

{{% capture body %}}

做一周的 PR 管理者

SIG Docs 的 approvers 可以成为 PR 管理者。SIG Docs approvers 会每周轮换地加入到 PR 管理者轮换日程中。

PR 管理者的工作职责包括：

• 每天检查悬决的 PR 的质量并确保它们遵守[风格指南]](/docs/contribute/style/style-guide/)。
  • 首先查看最小的 PR（size/XS），然后逐渐扩展到最大的 PR（size/XXL）。
  • 尽可能多地审阅 PR。
• 确保每个贡献者完成 CLA 签署。
  • 指导新的贡献者签署 CLA。
  • 使用此脚本自动提醒尚未签署 CLA 的贡献者签署 CLA。
• 针对所建议的更改提供反馈，并帮助协调其他 SIG 成员进行技术审核。
  • 为 PR 所建议的内容更改提供在线反馈。
  • 如果您需要验证内容，请在 PR 上发表评论并要求贡献者提供更多细节。
  • 设置相关的 sig/ 标签。
  • 如果需要，请从文件开头的 reviewers: 块中指定审阅者。
  • 设置 Docs Review 和 Tech Review 标签以标示 PR 的审阅状态。
  • 为尚未审阅的 PR 设置 Needs Doc Review 或者 Needs Tech Review 标签。
  • 为已审阅的但在合并前需要更多信息的或采取措施的 PR 设置 Doc Review: Open Issues 或者 Tech Review: Open Issues 标签。
  • 为可以合并的 PR 添加 /lgtm 和 /approve 标签。
• 合并已经就绪的，或关闭不应该接受的 PR。
• 每天对新增的 issues 进行分类和标记。有关 SIG 文档如何使用 metadata 的准则，请参见中级贡献。

对于负责人有用的 GitHub 查询

执行管理操作时，以下查询很有用。完成以下三个查询后，剩余的要审阅的 PR 列表通常很小。

• 没有签署 CLA, 不能 merge: 提醒贡献者签署 CLA。如果机器人和审阅者都已经提醒他们，请关闭 PR，并提醒他们在签署 CLA 后可以重新提交。 在作者没有签署 CLA 之前，不要审阅他们的 PR！
• 需要 LGTM: 如果需要技术审查，请告知机器人所建议的审阅者。如果 PR 需要文档审查或复制编辑，提交更改建议或向 PR 提交一个 copyedit 以使之进入下一步。
• 有 LGTM ，需要批准: 确定 PR 是否需要进行其他更改或更新才能合并。如果您认为 PR 已准备好合并，请输入 /approve。
• 非 master 分支的 PR： 如果 PR 针对 dev- 分支，则表示它适用于即将发布的版本。请添加带有 /assign @<负责人的 github 账号> 的注释，确保发行版本负责人注意到该 PR。如果 PR 是针对旧分支，请帮助 PR 作者确定是否所针对的是最合适的分支。

什么时候关闭 PR

审查和批准是缩短和更新我们的 PR 队列的一种方式；另一种方式是关闭 PR。

• 关闭两个星期未签署 CLA 的 PR。 PR 作者可以在签署 CLA 后重新打开 PR，因此这是确保未签署 CLA 的 PR 不会被合并的一种风险较低的方法。

• 如果作者在两周或更长时间内未回复评论或反馈，请关闭 PR。

不要害怕关闭 PR。贡献者可以轻松地重新打开并继续工作。通常，关闭通知会激励作者继续完成其贡献。

要关闭 PR，请在 PR 上输入 /close。

{{< note >}}

一项名为 fejta-bot 的自动服务会在 issues 停滞 90 天后会自动将其标记为过期；然后再等 30 天，如果仍然无人过问，则将其关闭。PR 管理者应该在 issues 处于无人过问状态 14-30 天后关闭它们。

{{< /note >}}

提出改进建议

SIG Docs 的 成员 可以提出改进建议。

在对 Kubernetes 文档贡献了一段时间后，你可能会对样式指南、用于构建文档的工具链、网页样式、评审和合入 PR 的流程，或者文档的其他方面产生改进的想法。为了尽可能透明化，这些提议都需要在 SIG Docs 会议或 kubernetes-sig-docs 邮件列表上讨论。此外，在提出全面的改进之前，它能真正帮助我们了解有关“当前工作如何运作”和“以往的决定是为何做出”的背景。想了解文档的当前运作方式，最快的途径是咨询 kubernetes.slack.com 中的 #sig-docs 聊天群组。

在进行了讨论并且 SIG 就期望的结果达成一致之后，你就能以最合理的方式处理改进建议了。例如，样式指南或网站功能的更新可能涉及 PR 的新增，而与文档测试相关的更改可能涉及 sig-testing。

为 Kubernetes 版本发布协调文档

SIG Docs 的批准者（approvers） 可以为 Kubernetes 版本发布协调文档。

每一个 Kubernetes 版本都是由参与 sig-release 的 SIG（特别兴趣小组）的一个团队协调的。指定版本的发布团队中还包括总体发布牵头人，以及来自 sig-pm、sig-testing 的代表等。了解更多关于 Kubernetes 版本发布的流程，请参考 https://github.com/kubernetes/sig-release。

SIG Docs 团队的代表需要为一个指定的版本协调以下工作：

• 通过特性跟踪表来监视新功能特性或现有功能特性的修改。如果版本的某个功能特性的文档没有为发布做好准备，那么该功能特性不允许进入发布版本。
• 定期参加 sig-release 会议并汇报文档的发布状态。
• 评审和修改由负责实现某功能特性的 SIG 起草的功能特性文档。
• 合入版本发布相关的 PR，并为对应发布版本维护 Git 特性分支。
• 指导那些想学习并有意愿担当该角色的 SIG Docs 贡献者。这就是我们常说的“实习”。
• 发布版本的组件发布时，相关的文档更新也需要发布。

协调一个版本发布通常需要 3-4 个月的时间投入，该任务由 SIG Docs approvers 轮流承担。

担任新的贡献者大使

SIG Docs approvers 可以担任新的贡献者大使。

新的贡献者大使共同努力欢迎 SIG-Docs 的新贡献者，对新贡献者的 PR 提出建议，以及在前几份 PR 提交中指导新贡献者。

新的贡献者大使的职责包括：

• 可在 Kubernetes #sig-docs 频道 上回答新贡献者的问题。
• 与 PR 管理者合作为新参与者寻找合适的第一个 issues。
• 通过前几个 PR 指导新贡献者到文档存储库。
• 帮助新的贡献者创建成为 Kubernetes 成员所需的更复杂的 PR。
• 为贡献者提供担保，使其成为 Kubernetes 成员。

当前新贡献者大使将在每次 SIG 文档会议上以及 Kubernetes #sig-docs 频道中宣布。

为新的贡献者提供担保

SIG Docs 的 reviewers 可以为新的贡献者提供担保。

新的贡献者针对一个或多个 Kubernetes 项目仓库成功提交了 5 个实质性 PR 之后，就有资格申请 Kubernetes 组织 成员身份。贡献者的成员资格需要同时得到两位 reviewers 的保荐。

新的文档贡献者可以通过咨询 Kubernetes Slack 实例 上的 #sig-docs 频道或者 SIG Docs 邮件列表来请求评审者保荐。如果你对申请人的工作充满信心，你自愿保荐他们。当他们提交成员资格申请时，回复 “+1” 并详细说明为什么你认为申请人适合加入 Kubernetes 组织。

担任 SIG 联合主席

SIG Docs approvers 可以担任 SIG Docs 的联合主席。

前提条件

Approvers 必须满足以下要求才能成为联合主席：

• 已维持 SIG Docs approver 身份至少 6 个月
• 曾领导 Kubernetes 文档发布 或者在两个版本发布中有实习经历
• 理解 SIG Docs 工作流程和工具：git、Hugo、本地化、博客子项目
• 理解其他 Kubernetes SIG 和仓库会如何影响 SIG Docs 工作流程，包括：k/org 中的团队、k/community 中的流程、k/test-infra 中的插件、SIG Architecture 中的角色。
• 在至少 6 个月的时段内，确保每周至少投入 5 个小时（通常更多）

职责范围

联合主席主要提供以下服务： 联合主席负责处理流程和政策、时间安排和召开会议、安排 PR 管理员、以及一些其他人不想做的事情，目的是增长贡献者团队。

职责范围包括：

• 保持 SIG Docs 专注于通过出色的文档最大限度地提高开发人员的满意度
• 以身作则，践行社区行为准则 并要求 SIG 成员对自身行为负责
• 通过更新贡献准则，为 SIG 学习并设置最佳实践
• 安排和举行 SIG 会议：每周状态更新，每季度回顾/计划会议以及其他需要的会议
• 在 KubeCon 活动和其他会议上安排和负责文档工作
• 与 {{< glossary_tooltip text="CNCF" term_id="cncf" >}} 及其尊贵合作伙伴（包括 Google、Oracle、Azure、IBM 和华为）一起以 SIG Docs 的身份招募和宣传
• 负责 SIG 正常运行

召开高效的会议

为了安排和召开高效的会议，这些准则说明了如何做、怎样做以及原因。

坚持社区行为准则：

• 相互尊重地、包容地进行讨论。

设定明确的议程：

• 设定清晰的主题议程
• 提前发布议程

对于每周一次的会议，请将前一周的笔记复制并粘贴到笔记的“过去的会议”部分中

通过协作，完成准确的记录：

• 记录会议讨论
• 考虑委派笔记记录员的角色

清晰准确地分配执行项目：

• 记录操作项，分配给它的人员以及预期的完成日期

根据需要来进行协调：

• 如果讨论偏离议程，请让参与者重新关注当前主题
• 为不同的讨论风格留出空间，同时保持讨论重点并尊重人们的时间

尊重大家的时间:

• 准时开始和结束会议

有效利用 Zoom：

• 熟悉 Kubernetes Zoom 指南
• 输入主持人密钥登录时声明主持人角色

录制 Zoom 会议

准备开始录制时，请单击“录制到云”。

准备停止录制时，请单击“停止”。

视频会自动上传到 YouTube。

{{% /capture %}}