如果您打算添加、更改或移除面向用户的功能，或者对 Bazel 进行重大架构更改，则必须编写设计文档并进行审核，然后才能提交更改。
以下是一些重大变更示例：
- 添加或删除原生 build 规则
- 对原生规则的破坏性更改
- 对原生 build 规则语义所做的更改，会影响多条规则的行为
- Bazel 规则定义 API 的变更
- Bazel 用于连接到其他系统的 API 的变更
- Starlark 语言、语义或 API 的更改
- 可能会对 Bazel 性能或内存用量产生广泛影响的更改（无论是好是坏）
- 对广泛使用的内部 API 的更改
- 更改了标志和命令行界面。
设计审核的原因
编写设计文档时，您可以与其他 Bazel 开发者协调，并向 Bazel 核心团队寻求指导。例如，如果提案添加、移除或修改了 BUILD、WORKSPACE 或 bzl 文件中提供的任何函数或对象，请将 Starlark 团队添加为审核者。设计文档在提交前会接受审核，原因如下：
- Bazel 是一个非常复杂的系统；看似无害的本地更改可能会产生重大的全局影响。
- 该团队会收到来自用户的许多功能请求；在评估这些请求时，不仅要考虑技术可行性，还要考虑相对于其他功能请求的重要性。
- Bazel 功能通常由核心团队之外的人员实现；此类贡献者的 Bazel 专业知识水平差异很大。
- Bazel 团队本身的专业知识水平不尽相同；没有任何一位团队成员能完全了解 Bazel 的方方面面。
- 对 Bazel 所做的更改必须考虑向后兼容性，并避免破坏性更改。
Bazel 的设计审核政策有助于最大限度提高以下可能性：
- 我们会对所有功能请求进行基本审核。
- 在投入可能行不通的实现之前，合适的人员会对设计提出意见。
为帮助您上手，请查看 Bazel Proposals Repository 中的设计文档。设计仍在完善中，因此实现细节可能会随时间推移和反馈而发生变化。已发布的设计文档记录了初始设计，而非在设计实施过程中发生的持续变化。请务必参阅文档，了解当前 Bazel 功能的说明。
贡献者工作流程
作为贡献者，您可以撰写设计文档、发送拉取请求，并为您的提案请求审核员。
编写设计文档
所有设计文档都必须包含标题，其中包含：
- 作者
- 上次重大更改的日期
- 审核员列表，其中包括一位（且仅一位）主审核员
- 当前状态（草稿、审核中、已批准、已拒绝、正在实施、已实施）
- 讨论会话链接（将在公告发布后添加）
文档可以编写为可供所有人访问的 Google 文档，也可以使用 Markdown 编写。请参阅下文，了解 Markdown 与 Google 文档的对比。
对用户有明显影响的提案必须包含一个部分，其中记录对向后兼容性的影响（以及必要时发布计划）。
创建拉取请求
创建一个拉取请求 (PR) 以将文档添加到设计索引，从而分享您的设计文档。将您的 Markdown 文件或文档链接添加到您的 PR 中。
请尽可能选择主审核员，并抄送其他审核员。如果您未选择主审核员，Bazel 维护人员会为您的 PR 分配一位主审核员。
您创建 PR 后，审核人员可以在代码审核期间提供初步意见。例如，主审核员可以建议添加其他审核员，或指出缺少的信息。当主审核员认为可以开始审核流程时，会批准 PR。这并不意味着提案完美无缺或一定会获得批准；而是说提案包含足够的信息来开始讨论。
宣布新方案
提交 PR 后，向 bazel-dev 发送通知。
您可以复制其他群组（例如 bazel-discuss，以便从 Bazel 最终用户那里获取反馈）。
与审核者一起迭代
任何感兴趣的用户都可以对您的提案发表评论。尝试回答问题、阐明提案并解决疑虑。
讨论应在公告会话中进行。如果提案位于 Google 文档中，则可以改用评论（请注意，允许匿名评论）。
更新状态
迭代完成后，创建新的 PR 以更新提案的状态。将 PR 发送给同一主审核员，并抄送其他审核员。
如需正式接受提案，主审核员需要确保其他审核员同意此决定，然后批准 PR。
从首次公布到批准提案，中间必须至少间隔 1 周。这样可以确保用户有足够的时间阅读文档并分享他们的疑虑。
在提案获得批准之前，您可以先开始实施，例如作为概念验证或实验。不过，您无法在审核完成之前提交更改。
选择主审核员
主评价员应是具有以下特征的领域专家：
- 熟悉相关子系统
- 客观且能够提供有建设性的反馈
- 在整个审核期内可用，负责引导审核流程
不妨查看各种团队标签的联系人。
Markdown 与 Google 文档
我们接受这两种方式，请您自行决定最适合自己的方式。
使用 Google 文档的好处：
- 非常适合头脑风暴，因为上手非常简单。
- 协作编辑。
- 快速迭代。
- 轻松提出修改建议。
使用 Markdown 文件的好处：
- 用于建立关联的简洁网址。
- 修订版本的明确记录。
- 在公开链接之前，请务必设置访问权限。
- 可通过搜索引擎轻松搜索。
- 面向未来：纯文本不受任何特定工具的约束，也不需要连接到互联网。
- 即使作者已不在，您也可以更新这些内容。
- 这些数据可以自动处理（更新/检测死链接、提取作者列表等）。
您可以先在 Google 文档中进行迭代，然后再将其转换为 Markdown 以供日后参考。
使用 Google 文档
为了保持一致性，请使用 Bazel 设计文档模板。它包含必要的标题，并与其他 Bazel 相关文档保持一致的视觉效果。为此，请依次点击文件 > 复制，或点击此链接复制设计文档模板。
如需向所有人开放文档的访问权限，请依次点击共享 > 高级 > 更改…，然后选择“开启 - 知道链接的任何人”。如果您允许对文档添加评论，任何人都可以匿名评论，即使没有 Google 账号也可以。
使用 Markdown
文档存储在 GitHub 上，并使用 GitHub 风格的 Markdown（规范）。
创建一个 PR 以更新现有文档。重大更改应由文档审核员审核。任何人都可以批准琐碎的更改（例如拼写错误、格式错误）。
审核者工作流程
审核人员对设计文档进行评论、审核和批准。
一般审核员的责任
您负责审核设计文档、根据需要索要更多信息，以及批准通过审核流程的设计。
收到新提案时
- 快速浏览一下该文档。
- 如果缺少重要信息，或者设计不符合项目目标，请提供相关意见。
- 建议其他审核人员。
- 当 PR 准备好送审时，请批准该 PR。
审核流程
- 与设计作者就存在问题或需要澄清的问题进行对话。
- 在适当情况下，邀请应该了解该设计的非审核人员提供反馈。
- 确定作者必须解决哪些评论才能获得批准。
- 如果您对提案的当前状态满意，请在讨论会话中写入“LGTM”（Looks Good To Me，即“看起来不错”）。
请针对所有设计审核请求遵循此流程。如果影响 Bazel 的设计不在设计索引中，请勿批准。
主审核员的责任
您负责就是否实施待处理的设计做出决策。如果您无法执行此操作，则应指定合适的代理（将 PR 重新分配给代理），或将 bug 重新分配给 Bazel 管理员以供进一步处理。
审核流程
- 确保以建设性的方式推进评论和设计迭代流程。
- 在获得批准之前，请确保已解决其他审核员提出的问题。
在所有审核者都批准后
- 请确保在邮寄名单中发布通知后至少已过 1 周。
- 确保 PR 会更新状态。
- 批准提案作者发送的 PR。
拒绝设计
- 确保 PR 作者发送 PR；或者向他们发送 PR。
- PR 会更新文档的状态。
- 在文档中添加一条注释，说明设计在当前状态下无法获得批准的原因，并概述后续步骤（如果有，例如“重新审视无效的假设并重新提交”）。