> [!note] > An agent helped me draft this. ### Problem Getting MR reviews at GitLab is slow and frustrating. MRs — especially Rails MRs — routinely sit for days waiting for reviews. This hurts developer morale, slows delivery, and discourages engineers from breaking work into small, reviewable MRs. The current workflow relies on reviewer roulette (push-based assignment) and hoping someone picks it up. When that doesn't work, engineers post in Slack channels like `#backend_maintainers` or DM people directly. There's no single place to go when you need a review and no structured way for available reviewers to find work. The recent `#backend_maintainers_review_queue` experiment (#591762) validated the core insight: **engineers want a pull-based way to pick up reviews**. But a plain Slack channel with free-form messages has UX limitations: 1. **Permanently unread**: The channel quickly becomes a wall of messages that's easier to ignore entirely than to scan 2. **Manual status tracking**: The ✅ emoji convention works, but you still have to scroll through all messages to find the ones still waiting 3. **No lifecycle management**: Messages persist forever, even after MRs are merged. Stale requests clutter the view 4. **Only backend maintainer reviews**: Database reviews, frontend reviews, initial code reviews — all still scattered across different channels and DMs 5. **Only trivial MRs**: Scoped to low-context requests, while the MRs that hurt the most are the non-trivial ones waiting for days ### Proposal Create a **single bot-managed Slack channel for all MR review requests**, across all review types (backend, database, frontend, reviewer, maintainer). #### Core mechanic: main channel = active queue, daily thread = archive **The main channel only ever shows MRs that still need attention.** Once an MR is addressed, the bot deletes it from the main channel and moves it to a daily archive thread. ``` #mr-review-queue (main channel) ├── 🔷 !225509 — Fix Zoekt indexing for namespaces (dgruzd) — waiting 3d — 🔧 backend maintainer ├── 🔷 !225750 — Update search API docs (dgruzd) — waiting 2d — 🗄️ database reviewer ├── 🔷 !226100 — Add rate limiting to search (alice) — waiting 4h — 👁️ backend reviewer └── 🔷 !226200 — Fix N+1 in project search (bob) — waiting 1d — 🗄️ database maintainer 📋 Archive — March 12, 2026 (thread) ├── ✅ !225523 — Refactor search query builder — reviewed by @carol ├── ✅ !225400 — Fix flaky spec — approved by @dave └── ... ``` This means: - **Open the channel → see exactly what needs help.** If it's there, it needs a reviewer. No scanning, no checking reactions - **Channel unread badge becomes meaningful**: Unread = there's an MR waiting. Not "someone posted something 3 days ago that's already been handled" - **Old requests don't get buried**: They stay visible until addressed, regardless of when they were posted - **History is preserved**: The daily thread serves as an audit log of what was reviewed and by whom #### How it works 1. **Submit an MR**: Engineer sends a slash command specifying the MR and the review type needed: ``` /review https://gitlab.com/.../-/merge_requests/225509 backend-maintainer /review https://gitlab.com/.../-/merge_requests/225750 db-reviewer ``` The bot posts a formatted top-level message in the channel. When the review is done and the MR needs the next stage, the author re-submits with the new review type 2. **Pick up a review**: A reviewer reacts with ✅ on the message 3. **Bot moves it**: The ✅ reaction triggers the bot to **delete the top-level message** and archive it in the daily thread with who picked it up #### Review types and multi-stage reviews An MR often needs multiple rounds of review from different people (e.g., backend reviewer → database reviewer → backend maintainer). The bot handles this naturally: - **The author specifies the review type when submitting.** This is the most important piece of context in each queue entry — a database maintainer scanning the channel can instantly tell which MRs they can help with and skip the rest. Without it, every reviewer has to open every MR to figure out if they're the right person, which is friction that kills engagement - **An MR can re-enter the queue**: After one review stage is done (✅), the author re-submits for the next stage. The bot posts a new top-level message with the updated review type - MRs often get stuck between stages — the initial review is done but the author has to manually hunt for the next reviewer. The bot keeps the MR visible until all required reviews are complete #### Key design principles - **The channel IS the queue**: If a message is in the main channel, it needs attention. Period - **All review types, one place**: Backend, database, frontend, reviewer, maintainer — all in one channel. The review type label lets people filter visually - **Pull, not push**: No @-mentions or forced notifications. Engineers check the queue when they have review bandwidth - **Self-cleaning**: The bot manages the lifecycle. No stale messages, no manual cleanup - **Low friction to submit**: One slash command — not a manual message to compose - **Queue, not stack**: Messages ordered by wait time, oldest first. No LIFO bias ### Rollout plan 1. **Phase 1 — Prototype**: Build a simple Slack bot and deploy to a new channel. Invite early adopters from teams experiencing review delays 2. **Phase 2 — Broader adoption**: Announce to engineering. Gather feedback, iterate on the bot 3. **Phase 3 — Standard tooling**: If successful, establish as the default place to request reviews when roulette-assigned reviewers are unresponsive ### Implementation options | Option | Effort | Description | |--------|--------|-------------| | **Simple Slack workflow** | Low | Slack's built-in Workflow Builder — limited but fast to prototype | | **Custom Slack bot** | Medium | Small service (Ruby/Python) integrating Slack API + GitLab webhooks | | **GitLab Slack integration enhancement** | High | Contribute as a feature to GitLab's existing Slack integration | For Phase 1, a **custom Slack bot** provides the best balance of flexibility and speed. ### Success metrics - Reduction in average time-to-first-review for MRs posted to the queue - Reduction in average time-to-merge - Queue responsiveness: how long do MRs stay in the main channel before getting a ✅? - Subjective developer satisfaction (before/after) - Adoption rate across teams ### Open questions - Should the bot auto-import MRs from reviewer roulette assignments, or only manual submissions? - Should there be SLO-style escalation (e.g., "This MR has been waiting 48+ hours")? - How to handle cross-timezone review handoffs? - Can we integrate with GitLab's review request system to auto-update status? - Should team-level channels also be supported (same bot, separate channel per team)? ### Prior art & related issues - [`#backend_maintainers_review_queue`](#591762) — current experiment for low-context backend maintainer reviews (plain Slack channel, no bot) - [Consider a "pull-based approach" to reviews](https://gitlab.com/gitlab-org/gitlab/-/issues/385387) — original proposal by Lee Tickett (2022) - [Discussion in `#backend_maintainers`](https://gitlab.slack.com/archives/CJHPLRTRD/p1772060917135489) (2026-02) — Thong Kuah advocated for pull-based reviews; Lucas Charles noted the channel format is "inherently more like a stack than a queue" - [Database review workflow concerns](https://gitlab.slack.com/archives/C3NBYFJ6N/p1773240680532989) (2026-03) — parallel discussion about similar problems for database reviews