高级贡献
如果你已经阅读并掌握开始贡献和中级贡献,并准备了解更多贡献的途径,请阅读此文。您需要使用 Git 命令行工具和其他工具做这些工作。
做一周的 PR 管理者
SIG Docs 的 approvers 可以成为 PR 管理者。SIG Docs approvers 会每周轮换地加入到 PR 管理者轮换日程中。
PR 管理者的工作职责包括:
- 每天检查悬决的 PR 的质量并确保它们遵守[风格指南]](/docs/contribute/style/style-guide/)。
- 首先查看最小的 PR(
size/XS
),然后逐渐扩展到最大的 PR(size/XXL
)。 - 尽可能多地审阅 PR。
- 首先查看最小的 PR(
- 确保每个贡献者完成 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
。
注意:一项名为
fejta-bot
的自动服务会在 issues 停滞 90 天后会自动将其标记为过期;然后再等 30 天,如果仍然无人过问,则将其关闭。PR 管理者应该在 issues 处于无人过问状态 14-30 天后关闭它们。
提出改进建议
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 活动和其他会议上安排和负责文档工作
- 与 CNCF云原生计算基金会 及其尊贵合作伙伴(包括 Google、Oracle、Azure、IBM 和华为)一起以 SIG Docs 的身份招募和宣传
- 负责 SIG 正常运行
召开高效的会议
为了安排和召开高效的会议,这些准则说明了如何做、怎样做以及原因。
坚持社区行为准则:
- 相互尊重地、包容地进行讨论。
设定明确的议程:
- 设定清晰的主题议程
- 提前发布议程
对于每周一次的会议,请将前一周的笔记复制并粘贴到笔记的“过去的会议”部分中
通过协作,完成准确的记录:
- 记录会议讨论
- 考虑委派笔记记录员的角色
清晰准确地分配执行项目:
- 记录操作项,分配给它的人员以及预期的完成日期
根据需要来进行协调:
- 如果讨论偏离议程,请让参与者重新关注当前主题
- 为不同的讨论风格留出空间,同时保持讨论重点并尊重人们的时间
尊重大家的时间:
- 准时开始和结束会议
有效利用 Zoom:
- 熟悉 Kubernetes Zoom 指南
- 输入主持人密钥登录时声明主持人角色
录制 Zoom 会议
准备开始录制时,请单击“录制到云”。
准备停止录制时,请单击“停止”。
视频会自动上传到 YouTube。
反馈
此页是否对您有帮助?
感谢反馈。如果您有一个关于如何使用 Kubernetes 的特定的、需要答案的问题,可以访问 Stack Overflow. 在 GitHub 仓库上登记新的问题 报告问题 或者 提出改进建议.