如何在不催促審閱者的情況下減少拉取請求審閱時間
更快地進行首次審核的系統方法：正確測量佇列，找到真正的約束，並在不降低審核品質的情況下重新平衡工作。
衡量等待時間，而不是審查者的速度
首次審核延遲是指從變更準備好審核到第一個有意義的人工審核事件發生的時間。它是傳輸系統的屬性，而不是個人的表現等級。排除草稿、自動機器人評論以及作者請求審閱先前發生的事件。報告中位數以及分佈和覆蓋範圍：基於百分之十變化的中位數不應具有與基於完整審核事件的中位數相同的置信度。將等待時間與積極討論或修改變更的時間分開。
找到號碼後面的隊列
按儲存庫、團隊、變更大小、所有權區域、請求的審閱者和星期幾劃分等待時間。然後打開記錄。長時間的等待通常集中在一個小型的審閱者小組、一個所有權不明確、變化過大、時區切換或在發布邊界附近提交的工作的元件周圍。全球中位數隱藏了這些模式。尋找比審閱者吸收速度更快的需求以及在團隊之間反彈的變化。正確的干預取決於隊列；諸如在四小時內審查所有內容之類的通用目標很少能解決該限制。
在增加壓力之前重新平衡知識
當少數人收到最多的請求時，減少依賴，而不是要求他們更快工作。為定義的所有權領域添加後備審閱者，將經驗豐富的審閱者與學習者配對，輪換審閱職責窗口，並記錄反覆阻止批准的決策。保持更改較小，以便更多人可以安全地理解它們。如果確實需要專家審查，請在規劃過程中明確這種依賴。目標是建立一個更廣泛、可靠的審查網絡，並保護焦點時間，而不是針對同一專家的更大的通知流。
創建輕量級服務協議
團隊可以在變更準備就緒、審查請求如何路由、阻止評論的組成以及緊急變更如何升級等方面達成一致。有用的協議可能每天保留兩個審閱窗口，並要求作者在請求關注之前提供背景、測試、風險和推出說明。避免嚴格的個人回應目標。它們鼓勵膚淺的評論和不斷的打斷。幾週後使用實際佇列證據審查協議，然後如果相同的等待繼續存在，則調整儲存庫規則、團隊邊界或計畫假設。
一起檢查品質和流程
只有當更改保持可理解性和安全性時，更快的審查才是一種改進。追蹤後續修復、恢復訊號、重複審核以及事件連結和延遲。詢問審稿者新的工作流程是否可以保護深度工作以及作者是否收到有用的回饋。比較相似的時期，而不是慶祝一日的下跌。最好的結果不是盡可能小的數字；而是盡可能小的數字。這是一個可預測的審查系統，重要的變更可以快速獲得正確的專業知識，正常工作並不依賴英雄般的可用性。