本文档面向 Bazel 开源项目的维护人员。
如果您想为 Bazel 做出贡献，请改为阅读为 Bazel做出贡献。
本页面的目标是：
- 作为维护人员了解项目贡献流程的可信来源。
- 设定社区贡献者和项目维护人员之间的预期。
Bazel 的 核心贡献者团队 设有专门的 子团队来管理开源项目的各个方面。具体包括：
- 发布流程：管理 Bazel 的发布流程。
- Green Team：打造健康的规则和工具生态系统。
- Developer Experience Gardeners：鼓励外部贡献，审核 问题和拉取请求，并使我们的开发工作流程更加开放。
版本
持续集成
如需了解 Bazel 的 CI 基础架构，请参阅 bazelbuild/continuous-integration 代码库中的 Green 团队指南。
问题的生命周期
- 用户使用问题 模板 创建问题，该问题会进入待审核的未解决 问题池。
- Developer Experience (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 的提交内容导入 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 - 不太可能关闭的低优先级缺陷 或功能请求。如果更多用户受到影响，也可以保持开放以进行潜在的重新确定优先级。
- ice-box
- 我们目前没有时间处理或接受贡献的问题。我们将关闭这些问题，以表明没有人正在处理这些问题，但会随着时间的推移继续监控其有效性，并在足够多的人受到影响且我们有资源处理这些问题时恢复这些问题。与往常一样，即使这些问题已关闭，您也可以随时发表评论或添加反应。
团队标签
team-Android：Android 团队的问题- 联系人：ahumesky
team-Bazel：一般 Bazel 产品/策略问题- 联系人：sventiffe
team-Build-Language：BUILD、.bzl API 和 Stardoc 的问题。- 联系人：brandjon
team-Configurability：Configurability 团队的问题- 联系人：gregestren
team-Core：Core 团队的问题- 联系人：haxorz
team-Documentation：Documentation 团队的问题- 联系人：communikit
team-ExternalDeps：外部依赖项处理、Bzlmod、远程代码库、WORKSPACE 文件- 联系人：meteorcloudy
team-Local-Exec：Execution (Local) 团队的问题- 联系人：meisterT
team-OSS：Bazel OSS 团队的问题：安装、发布流程、Bazel 软件包、网站、文档基础架构- 联系人：meteorcloudy
team-Performance：Bazel Performance 团队的问题- 联系人：meisterT
team-Remote-Exec：Execution (Remote) 团队的问题- 联系人：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: * 标签，改用团队标签。