GitHub 與 GitLab 工程指標：可以比較什麼？
跨提供者建立共享交付模型，而無需假裝他們的審查、規劃和身分概念相同。
規範公共交付生命週期
GitHub 拉取請求和 GitLab 合併請求共享一個有用的核心：儲存庫、作者、狀態、建立時間、合併時間、目標分支、標籤、受讓人、請求的審查者、提交和提供者 URL。規範化模型可以支援兩個提供者之間的開放工作、合併時間、吞吐量、過時變更、貢獻者參與和儲存庫活動。在每一行上保留提供者和提供者記錄 ID，以便使用者可以開啟來源，這樣重複的同步會更新正確的記錄，而不是建立重複項。
保留差異而不是消除差異
這些提供者在審批規則、審閱者分配、草稿行為、事件 API、項目層次結構、標籤、里程碑、迭代以及跨群組或組織的身份顯示方式方面有所不同。不存在的欄位不會自動為零。標準化具有相同意義的內容，並保留其餘內容的特定於提供者的元資料。介面應盡可能使用提供者中立的語言（例如更改或拉取和合併請求），同時在使用者檢查記錄時顯示原始術語和連結。
將審核指標視為覆蓋範圍敏感的指標
更改可能會請求審閱者但未完成審閱事件、來自機器人的評論、後來被駁回的批准或未在 API 之間清晰映射的討論事件。將第一次審核定義為更改準備就緒後進行的有意義的人工審核，然後記錄所使用的證據和事件類型。始終排除已知的機器人。發布有多少更改具有可衡量的審核數據。在沒有可比較事件覆蓋範圍的情況下比較提供者中位數可能會產生看似精確但錯誤的結論。
刻意繪製規劃概念
GitLab 迭代通常屬於節奏組並代表過時的交付視窗。里程碑是一個單獨的概念，可以描述版本或更廣泛的目標。 GitHub 里程碑可以提供計劃窗口，而類似衝刺的行為可能存在於專案或標籤中。不要將每個里程碑重新命名為迭代或從日期推斷團隊。儲存提供者類型、標題、日期、父節奏或項目以及來源 URL。當概念支援不同的管理問題時，提供單獨的篩選器。
比較決策，而不是提供者功能計數
跨提供者報告在回答一個共同問題時最有用：等待審核的時間在哪裡增加？哪些工作流程正在改變？所有權集中在哪裡？在比較之前應用相同的時間視窗、儲存庫範圍、機器人策略和身分匹配。顯示每個提供者的覆蓋範圍並讓使用者深入了解來源。我們的目標不是更快地宣布一個平台；而是更快地宣布一個平台。它是為多提供者組織提供一個一致的觀點，同時尊重使證據值得信賴的語意。