如果您打算新增、變更或移除面向使用者的功能，或是對 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 文件比較。
對使用者有明顯影響的提案必須提供一節，說明對向後相容性造成的影響 (以及視需要提供推出計畫)。
建立提取要求
建立提取要求 (PR) 來將文件新增至設計索引，即可分享設計文件。在提交要求中加入 Markdown 檔案或文件連結。
盡可能選擇主要審查者，並將其他審查者設為副本收件人。如果您未選擇主要審查者，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 可供審查時核准。
在審查期間
- 與設計作者對話，討論有問題或需要說明的問題。
- 如有需要，請邀請非審查者提供意見，他們應會瞭解設計內容。
- 決定作者必須回覆哪些留言，才能獲得核准。
- 如果您對提案目前的狀態感到滿意，請在討論串中寫下「LGTM」(Looks Good To Me)。
請針對所有設計審查要求遵循這個程序。如果設計並未列入設計索引，請勿核准會影響 Bazel 的設計。
主審查者的職責
您負責決定是否要實作待處理的設計。如果無法執行此操作，請找出適當的代理人 (將 PR 重新指派給代理人)，或將錯誤重新指派給 Bazel 管理員，以便進一步處理。
在審查期間
- 確保意見和設計迭代程序能有建設性地向前推進。
- 在獲得核准前，請務必解決其他審查人員提出的疑慮。
所有審查人員都核准後
- 請確認自發布郵件列表公告以來，至少已過 1 週。
- 請確認 PR 更新了狀態。
- 核准提案作者傳送的 PR。
拒絕設計
- 請確認公關作者是否已傳送公關，或您是否已傳送公關給他們。
- PR 會更新文件的狀態。
- 在文件中新增註解，說明為何無法以目前狀態核准設計，並概略說明後續步驟 (例如「重新檢查無效的假設並重新提交」)。