## Problem GitLab's internal MR review process generates rich workflow data that is currently not available in any queryable form. Teams have no visibility into: - **Reviewer roulette composition** — how many engineers are available at any given time, and how this evolves over time - **Approval reset events** — when a file change invalidates a CODEOWNER approval (particularly from the `*` catch-all rule), how frequently this happens and what the downstream cost is on review cycle time - **MR review timeline** — time to first review request, time to first review, time to first approval, total cycle time A past attempt to surface some of this data used Sisense/Snowflake with system comment parsing as a workaround — a fragile approach with high maintenance cost. The need was surfaced directly by Thong Kuah (`` `@tkuah` ``, Principal Engineer, Tenant Scale) in a 1:1 interview in February 2025 as part of the MR Cycle Time Improvement initiative (https://gitlab.com/gitlab-org/gitlab/-/work_items/508116#note_2372951203). He identified two compounding problems: 1. **Too many required approvals** — added as compliance requirements, now getting out of hand 2. **Approval resets create an n² process** — changing a file that was already approved forces re-approval from all CODEOWNERS, making the only viable mitigation "keep MRs smaller" His explicit ask to Development Analytics: _"Have data about required approvals in Snowflake (to be able to compute average number of reviews)"_. That was ~14 months ago and we have not acted on it yet. His subsequent work on reducing the `*` CODEOWNERS rule (https://gitlab.com/gitlab-org/gitlab/-/work_items/594402) makes this even more timely. The merge request review process was also formally identified as a `group::development analytics` responsibility when the Engineering Productivity team was dissolved (https://gitlab.com/gitlab-org/quality/engineering-productivity/team/-/work_items/582). ## Goals 1. **Audit available data sources** — GitLab REST/GraphQL API, system notes, ClickHouse, Snowflake, the gitlab-roulette static site 2. **Identify gaps** — which events have no structured representation (e.g. approval reset system notes are unstructured text, reviewer assignment is not a queryable event stream) 3. **Prototype structured data collection** for the highest-value events 4. **Deliver a Grafana dashboard** covering: - Reviewer roulette availability over time (pool size, OOO rate) - Approval reset frequency and rate - MR review timeline (time to first review, time to first approval) ## Related - https://gitlab.com/gitlab-org/gitlab/-/work_items/508116#note_2372951203 — Interview with Thong Kuah on MR cycle time pain points (Feb 2025) - https://gitlab.com/gitlab-org/quality/engineering-productivity/team/-/work_items/332 — MR workflow automations roadmap (historical EP context) - https://gitlab.com/gitlab-org/gitlab/-/work_items/594402 — Reduce `*` CODEOWNERS rule (`` `@tkuah` `` — direct beneficiary of this data) - https://gitlab.com/gitlab-org/quality/analytics/team/-/work_items/31 — Dogfood intelligent reviewer selection - https://gitlab.com/groups/gitlab-org/quality/analytics/-/epics/33 — Expand ClickHouse data collection (broader initiative this fits within)