本指南面向 Bazel 开源项目的维护者。
如果您希望为 Bazel 做出贡献，请改为参阅为 Bazel 做出贡献。
本页的目标如下：
- 作为维护者了解项目贡献流程的可信来源。
- 为社区贡献者和项目维护者设定预期。
Bazel 的核心贡献者团队拥有专门的子团队来管理开源项目的各个方面。它们是：
- 发布流程：管理 Bazel 的发布流程。
- 绿色团队：打造由规则和工具组成的健康生态系统。
- 开发者体验园丁：鼓励外部贡献、审核问题和拉取请求，并使我们的开发工作流程更加开放。
版本
持续集成
请参阅 bazelbuild/continuous-integration 代码库中 Green 团队关于 Bazel CI 基础架构的指南。
问题的生命周期
- 用户使用问题模板创建问题，该问题会进入未审核的未解决问题池。
- 开发者体验 (DevEx) 子团队轮替成员会审核此问题。
- 如果问题不是 bug 或功能请求，DevEx 团队成员通常会关闭该问题，并将用户重定向到 StackOverflow 和 bazel-discuss，以便提高问题的曝光度。
- 如果问题属于社区拥有的某个规则代码库（例如 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) 以进行转派。
- TL 可以选择将 PR 分配给其他人进行审核。
- 指定的审核者会审核 PR，并与作者合作，直到 PR 获得批准或被舍弃。
- 如果获得批准，审核人员会将 PR 的提交内容imports到 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：Core 团队的问题- 联系人：haxorz
team-Documentation：文档团队的问题- 联系人：communikit
team-ExternalDeps：外部依赖项处理、Bzlmod、远程代码库、WORKSPACE 文件- 联系人：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: * 标签，改用团队标签。
如需查看完整标签列表，请点击此处。