如果您计划添加、更改或移除面向用户的功能，或者对 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) 以将文档添加到设计索引，以分享您的设计文档。可将您的 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 相关文档保持视觉一致性。为此，请依次点击 File > Make a copy，或点击此链接制作 Design 文档模板的副本。
如需让所有人都能读取您的文档，请依次点击共享 > 高级 > 更改...，然后选择“开启 - 知道链接的任何人”。如果您允许对文档发表评论，则任何人都可以匿名发表评论，即使没有 Google 帐号也无妨。
使用 Markdown
文档存储在 GitHub 上，并使用 GitHub 的 Markdown 变种（规范）。
创建 PR 以更新现有文档。重大变更应由文档审核人员审核。任何人都能够批准细微更改（例如拼写错误、格式设置）。
审核人员工作流程
审核者对设计文档发表评论、进行审核和批准。
审核员的一般职责
您负责审核设计文档，根据需要提供更多信息，并批准通过审核流程的设计。
当您收到新提案时
- 快速浏览文档。
- 如果缺少关键信息，或者设计与项目目标不符，请添加注释。
- 建议其他审核者。
- 在 PR 准备好接受审核后批准它。
在审核流程中
- 与设计作者就有问题或需要澄清的问题进行对话。
- 在适当情况下，邀请应了解相应设计的非审核者评论。
- 确定必须由作者解决哪些评论才能获得批准。
- 如果您对提案的当前状态感到满意，请在讨论会话中写下“LGTM”（看起来不错）。
对于所有设计审核请求，请按照此流程操作。如果影响 Bazel 的设计不在设计索引中，请勿批准。
首席审核员的职责
您负责决定待处理设计的实现。如果您无法做到这一点，则应确定合适的受托人（将 PR 重新分配给受托人），或者将 bug 重新分配给 Bazel 经理进行进一步处理。
在审核流程中
- 确保评论和设计迭代过程以建设性的方式推进。
- 在获得批准之前，请确保其他审核者的疑虑已解决。
经过所有审核者的批准
- 请确保邮寄列表上的通知至少已过了一周。
- 确保 PR 会更新状态。
- 批准提案作者发送的 PR。
拒绝设计
- 确保 PR 作者发送 PR；或向他们发送 PR。
- PR 会更新文件的状态。
- 向文档添加注释，说明设计在当前状态下无法获得批准的原因，并简要说明后续步骤（例如，“重新访问无效的假设并重新提交”）。