Bazel 会举办特殊兴趣小组 (SIG),以便专注于特定领域的协作,并支持 Bazel 所有者、维护者和贡献者之间的沟通和协调。此政策适用于 bazelbuild
。
SIG 的工作是公开进行的。SIG 的理想范围应涵盖一个定义明确的领域,其中大部分参与者来自社区。SIG 可以专注于 bazelbuild
中的社区维护的代码库(例如语言规则),也可以专注于 Bazel 代码库中的代码领域(例如远程执行)。
虽然并非所有 SIG 都具有相同的活力、范围广度或治理模式,但应该有充分的证据表明,如果成立兴趣小组,社区成员会愿意参与并做出贡献。加入之前,请先查看该团队的工作,然后与 SIG 负责人联系。会员资格政策因 SIG 而异。
查看 Bazel SIG 的完整列表。
非目标:SIG 不是什么
SIG 旨在促进对共享工作的协作。因此,SIG 具有以下特点:
- 不是支持论坛:邮寄名单和 SIG 是两码事
- 不立即需要:在项目的早期阶段,您可能不知道自己是否有共享的工作或协作者
- 不是免费劳动力:需要投入精力才能协作发展和协调工作
Bazel 所有者在创建 SIG 时采取保守的方法。由于在 GitHub 上启动项目非常简单,因此有很多协作途径,无需 SIG 即可实现。
SIG 生命周期
本部分将介绍如何创建 SIG。
研究和咨询
如需提议新的 SIG 组,请先收集证据以供审批,如下所述。您可以考虑以下一些可能的途径:
- 该团队要解决的一个或一系列清晰明确的问题
- 与受益的社区成员进行协商,同时评估好处和社区成员的承诺意愿
- 对于现有项目,请提供问题和 PR 中表明贡献者关心该主题的证据
- 群组可能要实现的目标
- 运行群组的资源要求
即使 SIG 的需求似乎不言自明,但研究和咨询对于该团队的成功仍然至关重要。
创建新组
新团队应按照以下流程进行授权。具体而言,必须证明:
- 明确的用途和对 Bazel 的益处(围绕子项目或应用领域)
- 有 2 名或更多愿意担任群组主管的贡献者、有其他贡献者,以及有群组需求的证据
- 每个群组都需要使用至少一个可公开访问的邮寄名单。SIG 可以重复使用某个公开列表(例如 bazel-discuss),请求 @bazel.build 列表,或创建自己的列表
- SIG 最初需要的资源(通常是邮寄名单和定期视频通话)。
- SIG 可以从
bazelbuild/community
中的目录或bazelbuild
GitHub 组织中的自有代码库中提供文档和文件。如果 SIG 选择在bazelbuild
GitHub 组织之外整理工作,则可以链接到外部资源 - Bazel 所有者批准或拒绝 SIG 申请,并根据需要咨询其他利益相关方
在进入流程的正式部分之前,您应咨询 Bazel 产品团队(product@bazel.build)。大多数 SIG 都要求先进行讨论和迭代,然后才能获得批准。
如需正式申请加入新团队,请将章程作为 PR 提交给 bazelbuild/community
,并在 PR 的评论中按照以下模板添加相应请求。获得批准后,系统会合并该组的 PR 并创建所需的资源。
新 SIG 的模板请求
如需申请新的 SIG,请使用社区代码库中的模板:SIG-request-template.md。
租船
如需成立团队,您需要制定章程,并且必须遵守 Bazel 行为准则。该群组的归档内容将会公开。群组成员资格可以是无需审批的公开资格,也可以是需要申请的资格(需要等待群组管理员批准)。
该宪章必须提名一名管理员。除了管理员之外,该群组还必须至少有一位负责人(这两者可以是同一人),该负责人将根据需要与 Bazel 产品团队协调,充当联系人。
群组创建者必须将其章程发布到群组邮寄名单。Bazel GitHub 组织中的社区代码库会归档此类文档和政策。随着组织不断完善其做法和惯例,他们应在社区代码库的相关部分更新其章程。
协作和包容
虽然没有强制要求,但该团队应选择通过安排的电话会议或聊天渠道进行协作来召开会议。所有此类会议都应在邮寄名单上公布,并在会议结束后将会议记录发送到邮寄名单。定期召开会议有助于提高 SIG 的问责力和进展。
Bazel 产品团队成员可能会主动监控该群组,并鼓励其根据需要进行讨论和采取行动。
启动 SIG
必需活动:
- 通知 Bazel 常规讨论群组 (bazel-discuss、bazel-dev)。
可选活动:
- 为 Bazel 博客创建博文
SIG 的运行状况和终止
Bazel 所有者会尽最大努力确保 SIG 的健康运行。Bazel 所有者有时会要求 SIG 主管报告 SIG 的工作进展,以便让更广泛的 Bazel 社区了解该团队的活动。
如果 SIG 不再有实用目的或没有感兴趣的社区,则可能会被归档并停止运营。Bazel 产品团队保留归档此类无活动 SIG 的权利,以维护项目的整体健康状况,但这并不是一个理想的结果。如果 SIG 认为自己已达到生命周期的终点,也可以选择解散。
备注
此内容改编自 TensorFlow 的 SIG 手册。