如果您计划添加、更改或移除面向用户的功能，或者对 Bazel 进行重大架构更改，则必须先撰写设计文档并让相关人员审核，然后才能提交更改。
以下是一些重大变更的示例：
- 添加或删除原生 build 规则
- 对原生规则的重大更改
- 对原生 build 规则语义的更改，会影响多条规则的行为
- 对 Bazel 的规则定义 API 的更改
- Bazel 用于连接到其他系统的 API 的更改
- 对 Starlark 语言、语义或 API 的更改
- 可能会对 Bazel 性能或内存使用情况产生广泛影响（无论是好是坏）的更改
- 对广泛使用的内部 API 的更改
- 对标志和命令行界面的更改。
设计审核的原因
撰写设计文档时，您可以与其他 Bazel 开发者协调，并向 Bazel 核心团队寻求指导。例如，当提案添加、移除或修改 BUILD、MODULE.bazel 或 bzl 文件中提供的任何函数或对象时，请添加 Starlark 团队作为审核者。 设计文档在提交之前会经过审核，因为：
- Bazel 是一个非常复杂的系统；看似无害的本地更改可能会产生严重的全局后果。
- 团队会收到许多用户提出的功能请求；这些请求不仅需要评估技术可行性，还需要评估相对于其他功能请求的重要性。
- Bazel 功能通常由核心团队以外的人员实现；此类贡献者的 Bazel 专业知识水平参差不齐。
- Bazel 团队本身的专业知识水平各不相同；没有一个团队成员完全了解 Bazel 的方方面面。
- 对 Bazel 的更改必须考虑向后兼容性，并避免重大更改。
Bazel 的设计审核政策有助于最大限度地提高以下可能性：
- 所有功能请求都会受到基本的审查。
- 在投入资金实施可能无效的设计之前，我们会征求相关人员的意见。
为了帮助您入门，请查看 Bazel 提案库中的设计文档。 设计仍在进行中，因此实现细节可能会随着时间的推移和反馈而发生变化。已发布的设计文档记录了初始设计，而不是设计实现过程中的持续更改。请务必参阅文档，了解当前 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 会更新文档的状态。
- 在文档中添加一条注释，说明设计方案为何无法按当前状态获得批准，并概述后续步骤（如有）（例如“重新审视无效的假设并重新提交”）。