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