高级贡献

高级贡献

如果你已经了解如何贡献新内容和评阅他人工作，并准备了解更多贡献的途径，请阅读此文。您需要使用 Git 命令行工具和其他工具做这些工作。

提出改进建议

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-testing 的代表等。要了解更多关于 Kubernetes 版本发布的流程，请参考 https://github.com/kubernetes/sig-release。

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

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

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

担任新的贡献者大使

SIG Docs 批准人（Approvers）可以担任新的贡献者大使。

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

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

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

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

为新的贡献者提供保荐

SIG Docs 的评审人（Reviewers）可以为新的贡献者提供保荐。

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

新的文档贡献者可以通过咨询 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 个小时（通常更多）