Review Stats and Promotion Justification

TL;DR

• Asked for stats to build a justification for a promotion push: 121 MRs reviewed since October 2025, 79 merged MRs authored, 14 documented review write-ups
• Maintainer feedback on my reviews has been consistently positive with zero blocking corrections; self-noted gaps (missed pagination reset, Rails-side depth) each showed up once and were later caught
• Drafted a Senior Frontend Engineer promotion proposal in my manager Agent 8807’s voice, citing effective_version work, 121 reviewed MRs, and the Catalog UX Principles doc
• Feeling pressure from submitting my maintainership MR and promotion proposal at the same time, which has me reflecting on wanting to do bigger things
• Miss the headspace I had as a contractor making bigger architectural decisions, though GitLab has been encouraging

Pulling the numbers

I asked for an evidence base by looking through all the MRs I’ve done so far, wanting honest, critical feedback to start a justification with. It found I’ve reviewed 121 MRs since October 2025 — about one every two to three days over roughly 10 months. 79 merged MRs were authored by me, about one every three days, roughly two per week. I’ve done 14 documented review write-ups in the trainee issue, and every maintainer feedback response was positive, with zero blocking corrections. Sampling my 12 most recent reviews, nearly all had maintainers approving as-is after my pass, with only non-blocking nits or follow-ups afterward — no recurring mistakes. Self-noted gaps: a missed pagination reset in one MR and a Rails-side depth issue in another, each showing up once and followed by catching that same class of issue later — which is the pattern reviewers want to see.

The promotion draft

I asked for stats representing workload, scope of failures, recurring mistakes, and consistency in review cycles as success criteria, and used that to draft a promotion proposal from Intermediate to Senior Frontend Engineer, written in my manager Agent 8807’s voice since he’s the one who submits the form. It covers business need (feature leadership, review capacity, product direction on the AI Catalog), impact examples (the effective_version versioning work, 121 reviewed MRs including catching security issues, and the Catalog UX Principles doc plus mentoring), and areas to grow (Rails/backend review depth, leading larger multi-engineer initiatives, public representation).

Feeling the pressure

Today has a lot on my plate — pressure to submit my maintainership MR and fill out the promotion proposal. It’s got me thinking about wanting to do bigger things that make a real change in the codebase, the way I did as a contractor making big architectural decisions and taking risks that largely paid off. Since starting at GitLab there’s been nothing but encouragement, but my work feels narrow compared to before, and I don’t want to overstep on things outside my team. It’s slowly eroded the headspace I used to be in a year or more ago, and I don’t like it.