社区成员资格
本文档概述了 Kubeflow 中贡献者角色的各种职责。Kubeflow 分为负责不同子项目/仓库的工作组。
大多数角色的职责范围限定在这些仓库内。
| 角色 | 职责 | 要求 | 定义方式 |
|---|---|---|---|
| 成员 | 社区的活跃贡献者 | 由 2 名 Kubeflow 成员赞助，并对项目有多次贡献 | Kubeflow GitHub 组织成员 |
| 评审者 | 评审其他成员的贡献 | 在仓库中有评审和编写历史 | OWNERS 文件中的 reviewer 条目 |
| 批准者 | 接受贡献的批准 | 对某个仓库有丰富经验的活跃评审者和贡献者 | OWNERS 文件中的 approver 条目 |
| 工作组负责人 (WG Lead) | 为工作组提供技术领导 | 具备提供有效技术领导的足够领域知识 | wgs.yaml 文件中的条目 |
| 工作组主席 (WG Chair) | 为工作组提供总体领导 | 具备提供有效领导的足够领域知识 | wgs.yaml 文件中的条目 |
| Kubeflow 指导委员会成员 | KSC 为整个 Kubeflow 项目提供领导 | 详情 | 成员 |
注意
有关工作组结构和职责的详细文档，请参见 wg-governance.md新贡献者
现有成员应欢迎新贡献者加入社区，帮助他们熟悉 PR 工作流程，并引导他们查看相关文档和交流渠道。
已建立的社区成员
已建立的社区成员应证明他们遵守本文档中的原则，熟悉项目组织、角色、政策、程序、惯例等，并具备技术和/或写作能力。特定角色的期望、职责和要求如下所述。
成员
成员是社区中*持续活跃*的贡献者。他们可以被分配 issue 和 PR，并且他们的 PR 会自动运行测试。成员应保持对社区的活跃贡献。
定义方式：Kubeflow GitHub 组织的成员
要求
- 在其 GitHub 账户上启用了双重认证
- 对项目或社区有至少 2-3 次代码贡献或非代码贡献。
- 已阅读贡献者指南。
- 由 2 名 Kubeflow 成员赞助。请注意赞助人的以下要求
- 在 kubeflow/internal-acls 仓库中使用成员资格模板开启一个 issue
- 确保在 issue 中 @ 提及您的赞助人
- 在 kubeflow/internal-acls 仓库中开启一个拉取请求 (pull request)
- 完成清单中的每个项目（预览当前版本的模板）
- 确保包含的贡献列表代表了您在项目中的工作。
- 让您的赞助评审者回复确认赞助
- 您的赞助人回复后，Kubeflow 团队将审核您的请求。任何缺失的信息将被要求提供
- 您的 PR 合并后，您将收到一封电子邮件（发送到您与 GitHub 关联的电子邮件地址），邀请您加入 Kubeflow GitHub 组织。按照说明接受您的成员资格。
- 要确认成员资格接受过程已完成，您可以在 https://github.com/orgs/kubeflow/people 搜索您的 GitHub 用户名。
职责
- 对分配给他们的 issue 和 PR 做出响应
- 通过参与以下活动，成为 Kubeflow 社区的积极参与者：
- 工作组会议
- Slack 讨论
- 项目讨论
- 对其所属团队的提及做出响应
- 对其贡献的代码拥有活跃的所有权（除非所有权已明确转移）
- 代码经过充分测试
- 测试始终通过
- 解决代码接受后发现的 bug 或问题
- 订阅 https://groups.google.com/g/kubeflow-discuss
注意
经常贡献代码的成员应主动进行代码评审，并努力成为他们活跃的子项目的主要评审者。权限
- 成员可以在开放的 PR 上执行
/lgtm。 - 他们可以被分配 issue 和 PR，其他人可以使用
/cc @username请求成员进行评审。 - 他们有资格被任命为 Kubeflow 发布经理
- 他们的 PR 可以自动运行测试。无需
/ok-to-test。 - 成员可以对带有
needs-ok-to-test标签的 PR 执行/ok-to-test，并使用诸如/close等命令关闭 PR。完整命令列表可在Prow 文档中找到
评审者
评审者能够对子项目的某些部分的代码进行质量和正确性评审。他们了解代码库和软件工程原理。
定义方式：Kubeflow 组织拥有的仓库中的 OWNERS 文件中的 reviewers 条目。
评审者身份可以限定在代码库的某些部分或整个代码库的根目录。
注意
接受代码贡献需要在分配的评审者之外至少有一名批准者。要求
以下适用于在 OWNERS 文件中成为评审者的代码库部分。
- 成员至少 3 个月
- 至少对代码库的 5 个 PR 进行过主要评审
- 评审或合并过至少 15 个重要的代码库 PR
- 了解代码库
- 通过在 GitHub issue 和 Slack 中回答用户问题，积极参与社区
- 由子项目批准者赞助
- 且没有其他批准者反对
- 通过更新 OWNERS 文件的 PR 完成
- 可以自荐或由该子项目的批准者提名
注意
工作组负责人可以在特殊情况下提名并批准不满足这些要求的评审者。虽然短期内可以接受，但工作组负责人应确保这些评审者最终满足要求以下适用于在 OWNERS 文件中成为评审者的代码库部分。
职责
- 社区成员应承担的所有职责
- 通过代码评审负责项目质量控制
- 专注于代码质量和正确性，包括测试和重构
- 也可能评审更全面的问题，但这并非要求
- 应及时响应评审请求
- 应通过在 GitHub issue 和 Slack 中回答问题积极参与社区
- 被分配与其专业子项目相关的 PR 进行评审
- 被分配与其专业子项目相关的测试 bug
权限
- 社区成员应享有的一切权限
- 代码评审者身份可能是接受大型代码贡献的先决条件
- 可能会在 PR 和 issue 评论上获得徽章
批准者
代码批准者既能评审代码贡献，也能批准代码贡献。代码评审侧重于代码质量和正确性，而批准侧重于对贡献的全面接受，包括：向后/向前兼容性、遵守 API 和标志约定、微妙的性能和正确性问题、与其他系统部分的交互、总体代码测试覆盖率等。
定义方式：Kubeflow 组织拥有的仓库中的 OWNERS 文件中的 approvers 条目。
批准者身份可以限定在代码库的某些部分或整个代码库的根目录。
要求
以下适用于在 OWNERS 文件中成为批准者的代码库部分。
- 已满足代码库
评审者角色的职责（如上所述）至少 3 个月 - 至少对代码库的 10 个重要 PR 进行过主要评审
- 评审或合并过至少 30 个代码库 PR
- 由工作组负责人或主席提名
- 且没有其他负责人或主席反对
- 通过更新相关 OWNERS 文件的 PR 完成
注意
工作组负责人可以在特殊情况下提名并批准不满足这些要求的批准者。虽然短期内可以接受，但工作组负责人应确保这些批准者最终满足要求职责
以下适用于在 OWNERS 文件中成为批准者的代码库部分。
- 评审者应承担的所有职责
- 批准者身份可能是接受大型架构贡献的先决条件
- 展示出良好的技术判断力
- 通过代码评审负责项目质量控制
- 专注于对贡献的全面接受，例如与其他功能的依赖关系、向后/向前兼容性、API 和标志定义等
- 应及时响应评审请求
- 评审后应及时响应拉取请求的合并请求
- 指导贡献者和评审者
权限
- 评审者应享有的一切权限
- 可以批准代码贡献以供接受
非活跃成员
成员是社区中持续活跃的贡献者。
维护健康社区的一个核心原则是鼓励积极参与。不可避免的是，人们的关注点会随时间而改变，不要求他们永远积极贡献。
然而，作为 Kubeflow GitHub 组织的成员，拥有更高的权限。这些能力不应由不熟悉 Kubeflow 组织当前状态的人使用。
因此，连续一段时间（1 年）没有活动且远离组织的成员将被从 Kubeflow GitHub 组织中移除，并在重新熟悉当前状态后需要再次经历组织成员资格流程。
如果 OWNERS 文件中列出的任何人变得非活跃，我们将这样做：
- 如果该人员在评审者部分，他们的 GitHub ID 将被从该部分移除。
- 如果该人员在批准者部分，他们的 GitHub ID 将被移到
emeritus_approvers部分。
如何衡量非活跃性
非活跃成员被定义为在 12 个月内，在任何组织中都没有技术和非技术贡献的 Kubeflow 组织成员。DevStats 提供了一种简单的方法来确定对 Kubeflow 的贡献
长时间没有参与项目，那些成员需要在重新熟悉当前状态后才能有效贡献。
致谢
本指南集主要受到 Kubernetes 成员资格指南 的启发。