Code Review Process Analysis

Executive Summary

The main issue in Adservio's code review process is not yet proven to be review quality or review speed. The clearest problem is that the process is not measured with reliable system-generated signals today, so it is difficult to distinguish real review bottlenecks from upstream waiting, large merge requests, or informal reviewer load imbalance.

That means the first useful report should not try to answer everything. It should establish a small, defensible scorecard that measures code review directly from GitLab activity and uses manual tools only for context, not for KPIs.

What This Report Tries To Answer

This baseline report focuses on four questions:

• Is review happening fast enough after an MR becomes reviewable?
• Is review creating useful feedback rather than acting as a formality?
• Is review load spread across the team or concentrated on a few people?
• Is the process helping reduce risk, or only adding waiting time before merge?

Current Process Assessment

Based on the current understanding, the code review process should be treated as its own operational stage rather than inferred from planning tools or mixed into broader delivery flow.

Current strengths

• The team appears to have a recognizable code review stage in practice.
• Merge requests in GitLab can provide system-generated events for a reliable first measurement pass.
• The process is mature enough to discuss improvement in terms of flow, quality, and ownership rather than inventing a workflow from scratch.

Current weaknesses

• There is no shared baseline for what "healthy code review" means in measurable terms.
• Manual status systems are not reliable enough for KPI reporting.
• Review delay, review depth, and reviewer capacity are not yet separated analytically.
• Large merge requests may be inflating review time, but this cannot yet be proven with current reporting.

Recommended First Scorecard

The first Adservio code review scorecard should stay intentionally small.

1. Responsiveness

Time to first review

• Definition: first non-author review action minus MR creation time.
• Why it matters: shows whether review pickup is fast enough.

Pickup SLA

• Definition: percentage of MRs that receive first review within 1 working day.
• Why it matters: converts individual timestamps into an easy team-level reliability signal.

2. Flow

Review duration

• Definition: merge time minus first reviewer action.
• Why it matters: shows how long work remains inside the review stage once review has actually begun.

Stale review queue

• Definition: percentage of open MRs waiting in review for more than 2 working days.
• Why it matters: surfaces operational bottlenecks that slow delivery even when overall throughput looks acceptable.

3. Review Quality

Review rounds

• Definition: the number of times review feedback is followed by author commits and another review pass.
• Why it matters: identifies whether reviews are clear and efficient or fragmented into too many loops.

Meaningful review rate

• Definition: percentage of MRs with non-author comments or change-request behavior rather than silent approval only.
• Why it matters: guards against approval theater.

4. Team Health

Reviewer concentration

• Definition: share of reviews handled by the top 3 reviewers.
• Why it matters: detects bottlenecks and knowledge silos.

Oversized MR rate

• Definition: percentage of MRs above the agreed changed-lines or changed-files threshold.
• Why it matters: large MRs are one of the most common causes of slow and shallow review.

Initial KPI Definitions

For the first implementation, use these event rules:

• MR opened: GitLab created_at
• First reviewer action: first non-author approval, review comment, or explicit change-request signal
• Review duration: merge timestamp minus first reviewer action timestamp
• Review round: reviewer feedback followed by author commits before final approval or merge
• Oversized MR: start with a simple threshold such as more than 500 changed lines or more than 20 files, then calibrate later

These definitions are not perfect, but they are objective enough to start a stable trendline.

What We Can Already Say

Even before pulling the first dataset, a few conclusions are already reasonable:

1. The biggest current gap is observability, not policy

The team may already have decent review behavior, but there is no compact scorecard proving whether pickup is timely, review is thorough, or load is shared. That makes process discussions harder than they need to be and turns improvement conversations into anecdotal debate.

2. Manual workflow tools should not be used to judge review performance

Monday.com should be treated as a planning and communication layer only. It may still help contextualize work, but it should not appear in the code review KPI model.

3. The first reporting version should favor trust over completeness

It is better to have 6 reliable metrics from GitLab than 20 mixed metrics that combine manual state, inferred timing, and inconsistent operational habits.

Likely Process Risks To Test First

These are the first hypotheses worth validating once the data is extracted:

• Review pickup may be delayed because reviewer ownership is not explicit enough.
• A small number of people may be carrying too much review volume.
• Merge request size may be a stronger predictor of review delay than repository or team.
• Some approvals may be too lightweight to function as real quality gates.
• Long review cycles may come from unclear expectations before review starts, not just reviewer slowness.

Suggested Improvement Actions

These are the most practical first actions, even before deep analytics:

1. Define a code review service level expectation. Target a first review within 1 working day for normal merge requests.
2. Publish reviewer ownership by area. Every repository or code area should have a clear default reviewer path so MRs do not wait for social discovery.
3. Add a merge request size guardrail. Flag oversized MRs early so the team can split them before review becomes slow and shallow.
4. Introduce a lightweight review checklist. The checklist should cover risk, testing, backward compatibility, and readability, not just style.
5. Create a stale review view. The team should be able to see open MRs aging in review without manual searching.

Proposed Reporting Format

The first recurring code review report should contain:

1. Executive summary — One paragraph with overall health and the top 3 signals.
2. Weekly scorecard — Current week, last 4-week average, target, trend direction.
3. Queue health — Open MRs still waiting, oldest review items, stale count.
4. Quality signals — Review rounds, meaningful review rate, oversized MR rate.
5. Team load — Reviewer concentration, review volume by repo or team.
6. Actions — No more than 3 improvement actions for the next cycle.

Data Requirements For Version 1

To build the first measurable report, extract from GitLab:

• MR id and title
• author
• reviewers
• created time
• first review event time
• approval events
• comment events
• merge time
• changed files
• additions and deletions
• commits pushed after review started

Optional later enrichment:

• Jira key for grouping by product area
• post-merge bug or hotfix correlation

Confidence And Gaps

Confidence in this baseline report is medium.

What is solid:

• the measurement model
• the separation between reliable and unreliable sources
• the shortlist of likely bottlenecks and first improvement actions

What is still missing:

• actual GitLab extraction
• repository-specific baselines
• working-day normalization
• evidence on whether review depth is sufficient in practice

Recommended Next Step

Build version 1 as a GitLab-only report with the six headline KPIs below:

• time to first review
• pickup SLA
• review duration
• stale review queue
• reviewer concentration
• oversized MR rate

Once those metrics are stable for several weeks, add review rounds, meaningful review rate, and post-merge defect correlation as phase 2.