如果您打算新增、變更或移除面向使用者的功能，或是對 Bazel 進行重大架構變更，則必須撰寫設計文件並經過審查，才能提交變更。
以下列舉一些重大變更：
- 新增或刪除原生建構規則
- 原生規則的破壞性變更
- 變更原生建構規則語意，影響更多 超過一項規則
- Bazel 的規則定義 API 異動
- Bazel 用來連線至其他系統的 API 有所異動
- Starlark 語言、語意或 API 的變更
- 可能會對 Bazel 效能或記憶體用量造成全面性影響的變更 (無論是好是壞)
- 大量使用的內部 API 變更
- 標記和指令列介面變更。
設計審查的原因
撰寫設計文件時，您可以與其他 Bazel 開發人員協調，並向 Bazel 核心團隊尋求指引。舉例來說，如果提案新增、移除或修改 BUILD、WORKSPACE 或 bzl 檔案中可用的任何函式或物件，請將 Starlark 團隊設為審查者。我們會在提交前審查設計文件，原因如下：
- Bazel 是一個非常複雜的系統，看似無害的本機變更可能會對整體產生重大影響。
- 團隊收到許多使用者要求的功能要求；一律需要 評估時，不只評估技術可行性，也重視 或是提出其他功能要求
- Bazel 功能往往是由核心團隊以外的人員實作； 這些貢獻者在 Bazel 專業知識的程度上各有不同
- Bazel 團隊本身擁有不同程度的專業知識，沒有任何一位團隊成員能完全瞭解 Bazel 的每個層面。
- Bazel 的異動必須考量回溯相容性，避免中斷 並輸入變更內容
Bazel 的設計審查政策有助於盡可能提高以下情況：
- 所有功能要求都會先接受以基準級審查。
- 也就是我們的設計原則 可能無法執行
為協助您踏出第一步，請參閱 Bazel Ideas Repository。 設計仍在開發中，因此實作細節可能會隨著時間和意見回饋而變更。發布的設計文件會擷取初始設計 而不會在設計過程中持續做出變更。請務必參閱說明文件，瞭解目前的 Bazel 功能。
貢獻者工作流程
身為貢獻者，您可以撰寫設計文件、傳送提取要求，以及 為您的提案請求審查人員
撰寫設計文件
所有設計文件都必須具有包含以下內容的標頭：
- 作者
- 上次重大變更的日期
- 審查員清單，包括一位 (且僅一位) 主審審查員
- 目前狀態 (草稿、審查中、已核准、已拒絕、正在執行、已執行)
- 討論串連結 (將於公告後新增)
您可以將文件設為可供所有人閱讀的 Google 文件，也可以使用 Markdown 編寫文件。請參閱下方 Markdown 與 Google 文件比較。
如果提案對使用者的影響不可見，就必須提供部分 對回溯相容性的影響 以及視需要推出發布計畫
建立提取要求
建立提取要求 (PR) 來將文件加入 在提交要求中加入 Markdown 檔案或文件連結。
盡可能選擇主要審查者，並將其他審查者設為副本收件人。如果您未選擇主要審查者，Bazel 維護者會為您的 PR 指派一位審查者。
建立公關後，審查人員可以在 審查。舉例來說，待開發客戶審查人員可以建議其他評論者，或是 找出遺漏的資訊待開發客戶審查者在核准 PR 時核准 我們認為審查程序可以啟動這不表示提案是完美的 或核准後放送這表示提案所包含的資訊 即可開始討論
宣布新提案
傳送公告給 bazel-dev 代表 PR 已提交
您可以複製其他群組 (例如 bazel-discuss 取得 Bazel 使用者的意見回饋)。
與審查人員進行多次討論
任何有興趣的使用者都能對您的提案加註。嘗試回答問題、說明提案內容，並解決疑慮。
應在公告討論串中進行討論。如果提案內容位於 Google 文件中，可以改用註解 (請注意，匿名註解是允許的)。
更新狀態
在迭代完成後，建立新的 PR 來更新提案狀態。將 PR 傳送給同一位主要審查人員，並將其他審查人員設為副本。
如要正式接受提案，待開發客戶審查人員會在下列時間點過後核准 PR 確保其他審查員同意我們的決定。
首次發布公告和核准提案之間，必須至少相隔 1 週。這樣一來，使用者就能有足夠的時間閱讀文件，並表達自己的疑慮。
導入作業可以在接受提案前開始進行，例如 概念驗證或實驗不過，您無法提交變更 以免審查完成
選擇待開發客戶審查者
待開發客戶審查人員必須是下列領域的專家：
- 充分瞭解相關子系統
- 客觀且能提供建設性的意見
- 可在整個審查期間使用，以主導審查程序
建議您查看聯絡人的各種團隊標籤。
Markdown 與 Google 文件
由於兩種系統都接受評估，請找出最適合您的方式。
使用 Google 文件的優點：
- 這類活動適合腦力激盪，因為操作簡單。
- 協作式編輯。
- 快速疊代。
- 輕鬆提出修改建議。
使用 Markdown 檔案的好處：
- 乾淨用於連結的網址。
- 明確記錄修訂版本。
- 請勿忘記在發布連結前設定存取權。
- 輕鬆透過搜尋引擎搜尋資料。
- 未來可靠：純文字不受任何特定工具的限制，也不需要網際網路連線。
- 即使作者不再身邊，您也可以更新這些條款。
- 這些資料可以自動處理 (更新/偵測無效連結、擷取作者清單等)。
您可以選擇先在 Google 文件中進行疊代作業，然後轉換成 的 Markdown。
使用 Google 文件
為保持一致性，請使用 Bazel 設計文件範本。 其中包含必要的標頭，並與其他 Bazel 相關文件建立視覺一致性。如要這麼做，請依序點選「檔案」>「建立副本」，或點選這個連結來建立設計文件範本的副本。
如要讓所有人都能閱讀你的文件，請依序點選「分享」>「進階」>「變更」，然後選擇「開啟 - 任何知道連結的使用者」。如果你允許在文件中加註 任何人都可以匿名留言，即使沒有 Google 帳戶也不例外。
使用 Markdown
文件會儲存在 GitHub 上，並使用 GitHub 的 Markdown 格式 (規格)。
建立 PR 即可更新現有文件。文件審查人員應審查重大變更。三重變更 (例如錯字、格式) 則可由所有人核准
審查者工作流程
審查者的留言、審查和核准設計文件。
一般審查者責任
您負責審查設計文件、視需要要求提供額外資訊，以及核准通過審查程序的設計。
收到新提案時
- 快速查看這份文件。
- 如果缺少重要資訊，或設計不符合專案目標，請在評論中指出。
- 建議其他審查者。
- 當 PR 準備就緒時，請予以核准。
在審查期間
- 與設計作者對話，討論有問題或需要說明的問題。
- 如有需要，請邀請非審查者提供意見，他們應會瞭解設計內容。
- 決定作者必須回覆哪些留言，才能獲得核准。
- 如果您對提案目前的狀態感到滿意，請在討論串中寫下「LGTM」(Looks Good To Me)。
請按照這個程序處理所有設計審查要求。如果設計並未列入設計索引，請勿核准會影響 Bazel 的設計。
待開發客戶審查人員的責任
您必須自行負責在實作時做出 / 不做決定 以及尚待設計的設計初衷如果無法執行此操作，請找出適當的代理人 (將 PR 重新指派給代理人)，或將錯誤重新指派給 Bazel 管理員，以便進一步處理。
在審查期間
- 確保註解和設計反覆程序能繼續執行 建構出建構元件
- 在獲得核准前，請務必解決其他審查人員提出的疑慮。
所有審查者核准後
- 請確保您發布公告後至少有 1 週 郵寄清單。
- 請確認 PR 更新了狀態。
- 核准提案作者傳送的 PR。
拒絕設計
- 確認 PR 作者會傳送 PR；或是傳送 PR 給他們
- PR 會更新文件的狀態。
- 在文件中新增註解，說明為何無法以目前狀態核准設計，並概略說明後續步驟 (例如「重新檢查無效的假設並重新提交」)。