SataQiu
9.7 KiB
title, slug, content_template, weight
| title | slug | content_template | weight |
|---|---|---|---|
| 高级贡献 | advanced | templates/concept | 30 |
{{% capture overview %}}
如果你已经阅读并掌握开始贡献和中级贡献，并准备了解更多贡献的途径，请阅读此文。 您需要使用 Git 命令行工具和其他工具做这些工作。
{{% /capture %}}
{{% capture body %}}
做一周的 PR 管理者
SIG Docs 的审批者可以成为 PR 管理者。
SIG Docs 的审批者会每周轮换地加入到 PR 管理者轮换日程中。 PR 管理者的工作职责包括：
- 每天评审新增的 PR
- 指导新的贡献者签署 CLA，关闭两周都没有签署 CLA 的提交人的 PR。 PR 提交人在签署 CLA 之后可以重启 PR，所以 PR 管理者需要保证这段时间内相关文件没有合入。
- 对改进建议的更新提供反馈信息，包括促成其他 SIG 成员的技术性评审。
- 合入符合要求的 PR，关闭不符合要求的 PR。
- 每天筛选和标记新增的 issue。参见中级贡献中有关 SIG Docs 成员使用 metadata 的指南。
提出改进建议
SIG Docs 的成员可以提出改进建议。
在对 Kubernetes 文档贡献了一段时间后，你可能会对样式指南、用于构建文档的工具链、网页样式、评审和合入 PR 的流程，或者文档的其他方面产生改进的想法。为了尽可能透明化，这些提议都需要在 SIG Docs 会议或 kubernetes-sig-docs 邮件列表上讨论。此外，在提出全面的改进之前，它能真正帮助我们了解有关“当前工作如何运作”和“以往的决定是为何做出”的背景。想了解文档的当前运作方式，最快的途径是咨询 kubernetes.slack.com 中的 #sig-docs 聊天群组。
在进行了讨论并且 SIG 就期望的结果达成一致之后，你就能以最合理的方式处理改进建议了。例如，样式指南或网站功能的更新可能涉及 PR 的新增，而与文档测试相关的更改可能涉及 sig-testing。
为 Kubernetes 版本发布协调文档
SIG Docs 的审批者可以为 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 审批者轮流承担。
保荐新的贡献者
SIG Docs 的评审者可以保荐新的贡献者。
新的贡献者针对一个或多个 Kubernetes 项目仓库成功提交了 5 个实质性 PR 之后，就有资格申请 Kubernetes 组织成员。贡献者的成员资格需要同时得到两位评审者的保荐。
新的文档贡献者可以通过咨询 Kubernetes Slack instance 上的 #sig-docs 或 SIG Docs 邮件列表 来请求评审者保荐。如果你对申请人的工作充满信心，你自愿保荐他们。当他们提交成员资格申请时，回复“+1”并详细说明为什么你认为申请人适合加入 Kubernetes 组织。
{{% /capture %}}