本指南适用于 Bazel 开源项目的维护人员。
如果您希望为 Bazel 做贡献，请参阅为 Bazel 做贡献。
本页旨在：
- 充当项目的贡献流程的维护者可信来源。
- 在社区贡献者与项目维护者之间设定预期。
Bazel 的贡献者核心组拥有专门的子团队来管理该开源项目的方方面面。这些国家/地区包括：
- 发布流程：管理 Bazel 的发布流程。
- 绿色团队：打造一个健康规则和工具生态系统，
- 开发者体验园丁：鼓励外部人员贡献内容，审核问题并拉取请求，使我们的开发工作流更开放。
版本
持续集成
阅读针对 bazelbuild/持续集成代码库上的 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。 - 如果问题优先级较低且可由新的社区贡献者处理，DevEx 成员会分配
good first issue标签。在此阶段，问题会进入未分类的待解决问题池。
每个 Bazel 子团队最好对自己所拥有的标签的所有问题进行分类，最好每周一次。子团队将审核并评估问题，并尽可能提供解决方案。如果您是团队标签的所有者，请参阅此部分 了解详情。
问题解决后，便可将其关闭。
拉取请求的生命周期
- 用户创建拉取请求。
- 如果您是 Bazel 团队的成员，并在自己的领域发送 PR，则需自行分配您的团队标签并寻找最佳审核者。
- 否则，在日常分类中，DevEx 成员会分配一个团队标签和团队的技术主管 (TL) 进行路由。
- 团队负责人可以选择指定其他人来查看公共关系。
- 已分配的审核人员会审核 PR，并与作者合作，直到其获得批准或被弃用。
- 如果获得批准，审核人员会将 PR 的提交导入 Google 的内部版本控制系统，以供进一步测试。由于 Bazel 与 Google 在内部使用的构建系统相同，我们需要针对内部测试套件测试所有 PR 提交。正因如此，我们不会直接合并 PR。
- 如果导入的提交通过所有内部测试，则系统将压缩该提交并将其导出回 GitHub。
- 当提交合并到主实例时，GitHub 会自动关闭 PR。
我的团队拥有标签。该怎么做？
子团队需要对其拥有的标签中的所有问题进行分类，最好每周进行一次。
问题
- 按您的团队标签和
untriaged标签过滤问题列表。 - 查看问题。
- 确定优先级并分配标签。
- 如果 DevEx 子团队是 P0，则问题可能已优先处理。如有需要，请重新确定优先顺序。
- 每个问题都需要有一个优先级标签。如果某个问题是 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-CLI：控制台界面- 联系人：meisterT
team-Configurability：与可配置性团队有关的问题。包括：核心 build 配置和过渡系统。不包括：对新标志或现有标志的更改- 联系人：gregestren
team-Core：Skyframe、bazel 查询、BEP、选项解析、bazelrc- 联系人：haxorz
team-Documentation：文档团队的问题- 联系人：philomathing
team-ExternalDeps：外部依赖项处理、Bzlmod、远程代码库、WORKSPACE 文件- 联系人：meteorcloudy
team-Loading-API：build 文件和宏处理：标签、package()、可见性、glob- 联系人：brandjon
team-Local-Exec：执行（本地）团队问题- 联系人：meisterT
team-OSS：Bazel OSS 团队的问题：安装、发布流程、Bazel 打包、网站、文档基础架构- 联系人：meteorcloudy
team-Performance：Bazel 性能团队的问题- 联系人：meisterT
team-Remote-Exec：执行（远程）团队问题- 联系人：coeuvre
team-Rules-API：用于编写规则/方方面面的 API：提供程序、Runfile、操作、工件- 联系人：comius
team-Rules-CPP：C++ 规则（包括原生 Apple 规则逻辑）的问题- 联系人：oquenchil
team-Rules-Java：Java 规则问题- 联系人：hvadehra
team-Rules-Python：原生 Python 规则的问题- 联系人：rickeylev
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: * 标签，取而代之的是团队标签。
如需查看完整的标签列表，请点击此处。