如果您打算新增、變更或移除使用者提供的功能，或為 Bazel 進行重大架構變更，則必須撰寫設計文件並予以審查，再提交變更。
以下列舉幾個重大異動：
- 新增或刪除原生建構規則
- 對原生規則的破壞性變更
- 原生建構規則語意變更會影響多個規則的行為
- 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 Docs 比較。
具有使用者可見影響的提案，必須設有一個文件，記錄對回溯相容性的影響 (並視需要視需要推出推出計畫)。
建立提取要求
建立提取要求 (PR) 以將文件新增至設計索引，藉此分享您的設計文件。在 PR 中新增 Markdown 檔案或文件連結。
請盡可能選擇待開發客戶審查者，並向其他評論者發送副本。如果不選擇待開發客戶審查員，Bazel 維護人員會指派一位 PR 給 PR。
建立 PR 後，審查人員可以在程式碼審查期間進行初步註解。舉例來說，待開發客戶審查員可以建議其他審查人員，或是指出缺少資訊。待開發客戶審查員會在他們開始審查程序後核准 PR。這並不代表提案是完美的或獲準，代表提案包含的資訊足以開始討論。
宣布新提案
提交 PR 時，將公告傳送至 bazel-dev。
您可以複製其他群組 (例如 bazel-discuss，以取得 Bazel 使用者的意見回饋)。
與審查者進行疊代
任何感興趣的使用者都可以對您的提案留言。試著回答問題、釐清提案內容，並解決疑慮
討論時需透過公告會話串進行討論。如果提案位於 Google 文件中，您可以改用註解 (請注意，允許匿名註解)。
更新狀態
在疊代作業完成後，建立新的 PR 以更新提案狀態。將 PR 傳送給同一位待開發客戶審查員，並通知其他審查人員。
官方審查員在確認其他審查者同意此決定後，才正式核准提案審查人員。
第一次公告與提案核准之間須至少 1 週的時間。以確保使用者有足夠時間閱讀文件並提出疑慮。
可以在系統接受提案之前開始導入，例如做為概念驗證或實驗。然而，您無法在審查完成前提交變更。
選擇待開發客戶評論者
負責審核員必須是符合以下條件的專家：
- 對相關子系統的知識
- 客觀且能夠提供有建設性的意見
- 適用於整個審查期間，以便引導客戶完成這項程序
建議您查看聯絡人以瞭解各種小組標籤。
Markdown 與 Google 文件相比
請找出兩者中最好的，因為兩者都接受。
使用 Google 文件的好處：
- 可輕鬆開始腦力激盪，因為它可以輕鬆上手。
- 協同合作編輯功能。
- 快速疊代。
- 輕鬆提出修改建議。
使用 Markdown 檔案的好處：
- 清理網址以進行連結。
- 修訂版本的明確記錄。
- 發布連結前，別忘了要設定存取權嗎？
- 使用搜尋引擎輕鬆搜尋。
- 符合未來趨勢：純文字並非任何特定工具的混合物，不需要網際網路連線。
- 即使作者已經不在附近，您還是可以更新這些內容。
- 可自動處理這些作業 (更新/偵測無效連結、擷取作者清單等)。
您可以選擇先在 Google 文件中進行疊代，然後將其轉換成 Markdown 以使用便利性。
使用 Google 文件
為保持一致性，請使用 Bazel 設計文件範本。其中包含必要的標頭，可與其他 Bazel 相關文件建立視覺一致性。方法是按一下檔案 > [建立副本]，或按一下這個連結，建立設計文件範本的副本。
如要讓全世界的使用者都能存取您的文件，請依序按一下 [共用] > [進階] > [變更...]，然後選擇 [開啟 - 任何知道連結的使用者]。如果您允許在文件中加註，即使沒有 Google 帳戶，任何人都可以以匿名方式留言。
使用 Markdown
文件會儲存在 GitHub 上，並使用 Markdown 口味的 GitHub 變種版本 (規格)。
建立 PR 以更新現有文件。文件審查人員應進行重大變更。可有任何變更 (例如錯別字、格式設定) 可由任何人核准。
審查人員工作流程
審查人員在文件中加註、審核及核准文件。
一般評論者的責任
您必須負責審查設計文件，並視需要要求其他資訊，並核准通過審核程序的設計。
當您收到新的提案時
- 快速瞭解文件內容。
- 如果缺少重要資訊，或設計不符合專案目標，請加上註解。
- 建議其他審查者。
- 請 PR 核准審核。
審核期間
- 與設計作者對話，討論問題或需要釐清的問題。
- 如果適用，請邀請非評論者的評論，瞭解他們的設計。
- 決定哪些作者需要解決哪些留言， 才能獲準核准
- 當您對提案的目前狀態感到滿意時，請在討論執行緒中寫入「LGTM」(看起來不錯)。
針對所有設計審查申請流程進行這項程序。請不要核准影響 Bazel 於設計索引內的設計。
主管審閱者責任
您有責任在實作待處理的設計時決定執行 / 不做決定。如果無法這樣做，請找出合適的委派代表 (將 PR 重新指派給委派對象)，或將錯誤重新指派給 Bazel 管理員以進一步處理。
審核期間
- 請確保註解和設計疊代程序會逐漸進行。
- 核准前，請確認其他審查人員的疑慮均已解決。
所有審查者核准後
- 確認在郵寄清單上發布公告後，至少有 1 週的時間。
- 請確認 PR 已更新狀態。
- 核准提案作者所傳送的 PR。
拒絕設計
- 請確定 PR 作者傳送 PR 或寄送 PR。
- PR 會更新文件狀態。
- 在文件中新增註解，說明設計無法以目前狀態通過核准的原因，並列出後續步驟 (例如「再次造訪無效的假設並重新提交」)。