Bazel 特别兴趣组

Bazel 会托管特别兴趣小组 (SIG),以专注于特定领域的协作,并支持 Bazel 所有者、维护人员和贡献者之间的沟通与协调。本政策适用于 bazelbuild

SIG 会公开开展相关工作。SIG 的理想范围涵盖明确定义的领域,其中大多数参与来自社区。SIG 可以侧重于 bazelbuild 中由社区维护的代码库(例如语言规则),也可以重点关注 Bazel 代码库中的代码区域(例如 Remote Execution)。

虽然并非所有 SIG 的能力、范围或治理模式都相同,但应该有充分的证据表明,如果兴趣群体建立,有社区成员愿意参与和贡献。在加入之前,请先查看该群组的工作,然后与 SIG 负责人联系。会员政策因 SIG 而异。

请参阅 Bazel SIG 的完整列表。

非目标:SIG 不是什么

SIG 旨在促进共享工作上的协作。因此,SIG:

  • 不是支持论坛:邮寄名单和 SIG 是两码事
  • 无需立即使用:在项目生命周期的早期,您可能不知道自己是否共享过工作成果或协作者
  • 非自由劳工:为了促进和协调工作的协作,需要能源

Bazel Owner 采用保守的方法来创建 SIG,这要归功于在 GitHub 上轻松启动项目,并且无需 SIG 即可通过许多途径开展协作。

SIG 生命周期

本部分介绍了如何创建 SIG。

研究与咨询

如需提出新的 SIG 群组,请先收集证据以供审批,如下所述。您可以考虑采用以下几种方法:

  • 一组明确定义的问题,或者一组问题
  • 咨询将会受益的社区成员,评估受益及他们的承诺意愿
  • 对于现有项目,问题和 PR 提供的证据表明贡献者对相应主题感兴趣
  • 小组成员可能要实现的目标
  • 运行群组的资源要求

即使 SIG 的必要性似乎不言而喻,但研究和咨询对于该群体的成功仍然至关重要。

创建新群组

新小组应按照以下章程流程操作。具体而言,它必须证明:

  • 明确的目的和对 Bazel 的好处(围绕子项目或应用区域)
  • 两个或更多贡献者愿意充当群组负责人,是否存在其他贡献者,并且有证据表明他们对群组的需求
  • 每个群组都需要使用至少一个可公开访问的邮寄名单。SIG 可以重复使用其中一个公开列表(例如 bazel-think)请求 @bazel.build 的列表,也可以创建自己的列表
  • SIG 最初所需的资源(通常是邮寄名单和常规视频通话)。
  • SIG 可以从其 bazelbuild/community 中的目录或 bazelbuild GitHub 组织中自己的代码库提供文档和文件。如果 SIG 选择在 bazelbuild GitHub 组织之外组织其工作,则可以链接到外部资源
  • Bazel 所有者可以批准或拒绝 SIG 申请,并根据需要咨询其他利益相关方

在进入流程的正式部分之前,您应该通过 product@bazel.build 咨询 Bazel 产品团队。大多数 SIG 都需要在获得批准之前进行对话和迭代。

通过以下方法完成对新群组的正式请求:将章程作为 PR 提交到 bazelbuild/community,并按照下面的模板在 PR 上的注释中添加请求。获得批准后,系统会合并该组的 PR,并创建所需资源。

新 SIG 模板请求

如需请求新的 SIG,请使用社区代码库中的模板:SIG-request-template.md

包租

要建立群组,您需要一份章程,且必须遵循 Bazel 行为准则。群组的归档文件将会公开显示。成员资格可以不经批准便向所有人开放,也可以应要求在获得群组管理员批准后可用。

章程必须提名一名管理员。除了管理员之外,该群组必须至少包括一位负责人(可以是同一人),担任负责与 Bazel 产品团队进行协调的联系人。

群组创建者必须将章程发布到群组邮寄名单中。Bazel GitHub 组织中的社区代码库可归档此类文档和政策。随着群组不断完善其做法和惯例,他们应在社区代码库的相关部分更新其章程。

协作与包容

虽然没有强制性要求,但小组应选择通过预定的电话会议或聊天渠道来利用协作来进行会议。任何此类会议都应在邮寄名单中公布,并在之后发布到邮寄名单中。定期召开会议有助于推动 SIG 的问责制原则和进度。

Bazel 产品团队成员可以主动监控并鼓励团队根据需要进行讨论和采取行动。

发布 SIG

必需的活动:

可选活动:

  • 为 Bazel 博客创建博文

SIG 的健康和终止

Bazel 所有者要尽最大努力确保 SIG 的健康状况。Bazel 所有者偶尔会要求 SIG 负责人报告 SIG 的工作,以便将此群组的活动告知更广泛的 Bazel 社区。

如果 SIG 不再具有有用的用途或不再感兴趣的社区,则可能会遭到归档并停止运作。Bazel 产品团队保留通过归档此类非活跃 SIG 来维护项目的整体运行状况的权利,但这并不是一个可取的结果。如果 SIG 发现其使用寿命已过,也可以选择解散。

注意

此内容取自 Tensorflow 的 SIG 指南,并进行了修改。