本指南供 Bazel 开源项目的维护者参考。
如果您希望为 Bazel 贡献力量，请改为参阅为 Bazel 贡献数据。
本页面的目的是：
- 充当项目贡献流程的维护者可信来源。
- 在社区贡献者和项目维护者之间建立预期。
Bazel 的核心贡献者拥有专门的子团队来管理开源项目的各个方面。它们是：
- 发布流程：管理 Bazel 的发布流程。
- 绿色团队：发展一个由规则和工具组成的健康生态系统。
- 开发者体验园丁：鼓励外部贡献、审核问题和拉取请求，并使我们的开发工作流更加开放。
版本
持续集成
在 bazelbuild/Continuous-integration 代码库中阅读有关 Bazel 持续集成基础架构的 Green 团队指南。
问题的生命周期
- 用户使用问题模板创建问题，然后进入未审核的待解决问题池。
- 开发者体验 (DevEx) 子团队轮替的成员会审核此问题。
- 如果问题不是 bug 或功能请求，DevEx 成员通常会关闭问题并将用户重定向到 StackOverflow 和 bazel-think，以便提高相关问题的曝光度。
- 如果问题属于社区所拥有的某个规则代码库（例如 rules_apple），则 DevEx 成员会将此问题转移到正确的代码库。
- 如果问题不明确或缺少信息，DevEx 成员会将问题重新分配给用户，以要求提供更多信息，然后再继续。当用户未遵循问题模板时，通常就会发生这种情况。
- 在审核问题后，DevEx 成员会决定是否需要立即关注。如果分配了，该团队将分配 P0 优先级标签和一个团队负责人列表中的所有者。
- DevEx 成员为路由分配
untriaged标签和仅一个团队标签。 - DevEx 成员还会根据问题类型仅分配一个
type:标签，例如type: bug或type: feature request。 - 对于特定于平台的问题，DevEx 成员会分配一个
platform:标签，例如，特定于 Mac 的问题会为platform:apple。在此阶段，问题将进入未分类的待解决问题池。
每个 Bazel 子团队将根据各自的标签对所有问题进行分类，最好每周进行一次。该子团队将审核和评估问题，并尽可能提供解决方案。如果您是团队标签的所有者，请参阅此部分 了解详情。
问题解决后，可以将其关闭。
拉取请求的生命周期
- 用户创建拉取请求。
- 如果您是 Bazel 团队的成员并针对您所在的领域发送 PR，您将负责分配团队标签并找到最佳审核者。
- 否则，在每日分类中，DevEx 成员会分配一个团队标签和团队的技术负责人 (TL) 以分配路由。
- 团队负责人可以选择指派其他人审核 PR。
- 分配的审核人员审核 PR，并与作者合作，直到 PR 获得批准或被撤销。
- 如果获得批准，审核人员会将 PR 的提交内容导入 Google 的内部版本控制系统，以进行进一步测试。由于 Bazel 是 Google 在内部使用的构建系统，因此我们需要针对内部测试套件测试所有 PR 提交。这就是我们不直接合并 PR 的原因。
- 如果导入的提交通过所有内部测试，则该提交内容将被压缩，并将其导回到 GitHub。
- 当提交合并到主实例时，GitHub 会自动关闭 PR。
我的团队拥有一个唱片公司。该怎么做？
子团队需要按照自己的标签对所有问题进行分类，最好每周一次。
问题
- 您可以按团队标签和
untriaged标签过滤问题列表。 - 查看问题。
- 确定优先级并分配标签。
- 如果该问题的级别为 P0，DevEx 子团队可能已优先处理该问题。如有需要，请重新确定优先级。
- 每个问题只需要有一个优先级标签。如果问题为 P0 或 P1，我们假定该问题正在得到积极处理中。
- 移除
untriaged标签。
请注意，您必须位于 bazelbuild 组织中，才能添加或移除标签。
拉取请求
- 按您的团队标签过滤拉取请求列表。
- 查看待处理的拉取请求。
- 可选：如果您被分配给审核人员，但不适合该审核人员，请重新分配适当的审核人员以进行代码审核。
- 与拉取请求创建者合作完成代码审核。
- 批准 PR。
- 确保通过所有测试。
- 将补丁导入内部版本控制系统并运行内部预提交。
- 提交内部补丁。如果补丁成功提交和导出，GitHub 会自动关闭 PR。
优先级
维护者将使用下面的优先级定义来对问题进行分类。
- P0 - 重大功能故障，会导致 Bazel 版本（减去候选版本）无法使用，或者服务中断，服务严重影响 Bazel 项目的开发。这包括新版本中引入的会导致大量用户的回归问题，或不符合重大变更政策的不兼容重大更改。没有实际的解决方法。
- P1 - 应在下一个版本中解决的严重缺陷或功能，或者影响许多用户的严重问题（包括 Bazel 项目的开发），但实际存在的权宜解决方法。通常不需要立即采取措施。需求较高，已在本季度的路线图中规划。
- P2 - 应该解决但我们目前尚未解决的缺陷或功能。已发布的 Bazel 版本中存在中度实时问题，这会给用户带来不便，需要在未来的版本中得到解决，并且/或者存在简单的解决方法。
- P3 - 修复或增强了细微差别，可带来重要的 bug 修复或增强功能。不优先参与 Bazel 路线图或任何即将发布的版本，但鼓励社区贡献。
- P4 - 低优先级缺陷或不太可能达成的功能请求。也可以保持开放状态，以便有更多用户受到影响时，我们可能会重新确定应用的优先级。
- 冰箱
- 我们目前没有时间处理的问题，也没有时间接受贡献内容。我们将关闭这些问题，以表明没有人在处理这些问题，但会继续监控它们的有效性，并在有足够多的人员受到影响并且我们恰好有处理这些问题的资源时，恢复这些问题。与往常一样，即使问题关闭，也欢迎您发表评论或添加回应。
团队标签
team-Android：Android 团队遇到的问题- 联系人：ahumesky
team-Bazel：一般性 Bazel 产品/策略问题- 联系人：sventiffe
team-Build-Language：关于 build、.bzl API 和 Stardoc 的问题。- 联系信息：brandjon
team-Configurability：需要配置团队遇到的问题- 联系人：gregestren
team-Core：核心团队遇到的问题- 联系人：haxorz
team-Documentation：文档团队遇到的问题- 联系人：communikit
team-ExternalDeps：外部依赖项处理、Bzlmod、远程仓库、工作区文件- 联系人：meteorcloudy
team-Local-Exec：执行（本地）团队的问题- 联系人：meisterT
team-OSS：Bazel OSS 团队遇到的问题：安装、发布流程、Bazel 打包、网站、文档基础架构- 联系人：meteorcloudy
team-Performance：Bazel 性能团队的问题- 联系人：meisterT
team-Remote-Exec：执行（远程）团队的问题- 联系信息：coeuvre
team-Rules-CPP：C++ 规则（包括原生 Apple 规则逻辑）的问题- 联系人：oquenchil
team-Rules-Java：Java 规则的问题- 联系信息：comius
team-Rules-Python：原生 Python 规则的问题- 联系信息：comius
team-Rules-Server：Bazel 随附的服务器端规则的问题- 联系信息：comius
team-Starlark-integration：非 API Bazel + Starlark 集成。包括：Bazel 如何触发 Starlark 解释器、Stardoc、内置注入、字符编码。不包括：BUILD 或 .bzl 语言问题。- 联系信息：brandjon
team-Starlark-interpreter：Starlark 解释器的问题（java.net.starlark 中的任何内容）。build 和 .bzl API 问题（代表 Bazel 与 Starlark 的集成）出现在team-Build-Language中。- 联系信息：brandjon
对于新问题，我们废弃了 category: * 标签，取而代之的是团队标签。
请点击此处查看标签的完整列表。