GitHub 与 GitLab 工程指标：可以比较什么？
跨提供商构建共享交付模型，而无需假装他们的审查、规划和身份概念相同。
规范公共交付生命周期
GitHub 拉取请求和 GitLab 合并请求共享一个有用的核心：存储库、作者、状态、创建时间、合并时间、目标分支、标签、受让人、请求的审阅者、提交和提供者 URL。规范化模型可以支持两个提供商之间的开放工作、合并时间、吞吐量、过时更改、贡献者参与和存储库活动。在每一行上保留提供者和提供者记录 ID，以便用户可以打开源，这样重复的同步会更新正确的记录，而不是创建重复项。
保留差异而不是消除差异
这些提供者在审批规则、审阅者分配、草稿行为、事件 API、项目层次结构、标签、里程碑、迭代以及跨组或组织的身份显示方式方面有所不同。不存在的字段不会自动为零。标准化具有相同含义的内容，并保留其余内容的特定于提供者的元数据。界面应尽可能使用提供者中立的语言（例如更改或拉取和合并请求），同时在用户检查记录时显示原始术语和链接。
将审核指标视为覆盖范围敏感的指标
更改可能会请求审阅者但未完成审阅事件、来自机器人的评论、后来被驳回的批准或未在 API 之间清晰映射的讨论事件。将第一次审核定义为更改准备就绪后进行的有意义的人工审核，然后记录所使用的证据和事件类型。始终排除已知的机器人。发布有多少更改具有可衡量的审核数据。在没有可比事件覆盖范围的情况下比较提供商中位数可能会产生看似精确但错误的结论。
刻意绘制规划概念
GitLab 迭代通常属于节奏组并代表过时的交付窗口。里程碑是一个单独的概念，可以描述版本或更广泛的目标。 GitHub 里程碑可以提供计划窗口，而类似冲刺的行为可能存在于项目或标签中。不要将每个里程碑重命名为迭代或从日期推断团队。存储提供者类型、标题、日期、父节奏或项目以及源 URL。当概念支持不同的管理问题时，提供单独的过滤器。
比较决策，而不是提供商功能计数
跨提供商报告在回答一个共同问题时最有用：等待审核的时间在哪里增加？哪些工作流程正在发生变化？所有权集中在哪里？在比较之前应用相同的时间窗口、存储库范围、机器人策略和身份匹配。显示每个提供商的覆盖范围并让用户深入了解来源。我们的目标不是更快地宣布一个平台；而是更快地宣布一个平台。它是为多提供商组织提供一个一致的观点，同时尊重使证据值得信赖的语义。