How to Get Your GitLab Merge Requests Reviewed & Merged: A Practical Guide
Contributing to large open-source repositories like GitLab can feel intimidating at first. You put in the effort, fix an issue, write tests, open your Merge Requests (MRs)—and then... silence. Or maybe you get a green checkmark approval on one MR, but nothing merges, while two other MRs sit untouched.
If you are wondering:
- Why did my approved MR not get merged?
- Who is supposed to review my untouched MRs?
- Is it okay to ping someone, and who should I tag?
This guide walks you through the exact review lifecycle GitLab uses, how the automated triage works, and how to get your MRs moving across the finish line.
1. Understanding the GitLab Two-Tier Review Model
Unlike smaller GitHub projects where any maintainer might review and hit "Merge" in one step, GitLab follows a strict two-stage review structure:
[ Contributor ]
│
▼
[ Tier 1: Reviewer ] ── (Reviews code, leaves feedback, gives initial Approval)
│
▼
[ Tier 2: Maintainer ] ── (Performs final architectural review & executes Merge)
- Reviewers: Domain experts (Backend, Frontend, Database, UX, or Technical Writing). They inspect logic, style compliance, and test coverage. They can click Approve, but they typically do not have maintainer merge rights on the repository.
- Maintainers: Senior team members with write/merge permissions. Every MR must be approved by a designated Maintainer for each affected domain before it can merge into the default branch.
2. What to Do When You Have 1 Approval (Waiting for Next Steps)
If one of your MRs received an approval, check the profile/role of the person who approved it:
Case A: The Approver is a Reviewer (Not a Maintainer)
Your MR now needs a Maintainer handoff.
-
Check Reviewer Roulette: Look at the automated comment left on your MR by
@gitlab-bot. Find the Maintainer column for your domain. - Politely reply to your approver: > "Thanks for the review and approval @reviewer! Could you please pass this to a maintainer for final review, or should I ping the maintainer suggested by Reviewer Roulette?"
- Or hand off directly using Quick Actions:
/assign_reviewer @suggested_maintainer
/unassign_reviewer @previous_reviewer
Case B: The MR Touches Multiple Domains
If your MR touches both backend Ruby code and frontend Vue/TypeScript code, GitLab requires:
- 1 Frontend Reviewer + 1 Frontend Maintainer
- 1 Backend Reviewer + 1 Backend Maintainer
Check the Approval Rules widget near the top of the MR to see which specific groups still need approval.
3. What to Do When Your MRs Have 0 Reviews
If your MR is sitting without reviews, work through this pre-flight checklist before contacting anyone:
1. Is it marked as "Draft"?
If your MR title begins with Draft: or WIP:, reviewers and automation assume you are still working on it.
- Click Mark as ready in the MR header, or comment:
/ready
2. Is the CI/CD Pipeline Green?
Reviewers prioritize MRs with passing pipelines. If pipelines fail due to transient flakes, re-run failed jobs. If tests fail due to your changes, fix them first.
3. Check for the Community contribution Label
Ensure your MR has the ~"Community contribution" label. This label feeds directly into GitLab's internal dashboards monitored by Community Relations and MR Coaches.
/label ~"Community contribution"
4. Set the Workflow Status
GitLab's triage bots categorize MRs by workflow state. Tell the triage bots your MR is ready for eyes:
/label ~"workflow::ready for review"
5. Assign Reviewers via "Reviewer Roulette"
In the MR comments, find the table generated by @gitlab-bot titled Reviewer roulette. It intelligently suggests reviewers based on:
- Timezone overlap
- Current workload & Out-of-Office (OOO) status
- Domain expertise (Backend, Frontend, QA, Docs)
Copy the quick actions provided at the bottom of the bot's comment, or assign them manually:
/assign_reviewer @suggested_reviewer
4. Cheat Sheet: Essential GitLab Quick Actions (Slash Commands)
GitLab supports slash commands inside MR comments. You can paste these directly into a comment box:
| Goal | Command |
|---|---|
| Mark MR as ready | /ready |
| Mark back to draft | /draft |
| Assign a reviewer | /assign_reviewer @username |
| Remove reviewer | /unassign_reviewer @username |
| Request community coach help | /label ~"workflow::ready for review" |
| Rebase on target branch | /rebase |
5. Escalation: Who to Ping When MRs Are Stuck (After 5–7 Days)
Open-source maintainers balance high issue volumes. If an MR has had an assigned reviewer for 5 to 7 business days without response:
Step 1: Gentle Reminder on the MR
Leave a polite, succinct comment mentioning the assigned reviewer:
"Hi @reviewer, just following up to see if you have any feedback or if you need anything clarified on this MR. Thanks!"
Step 2: Tag GitLab Merge Request Coaches
GitLab employs designated Merge Request Coaches whose primary responsibility is helping community contributors navigate code review and triage.
Tag them directly on the MR thread:
"@gitlab-org/coaches Hi team! This community contribution has been ready for review for a few days. Could you please help route it to an available reviewer when you get a chance? Appreciate it!"
Step 3: Ask in the Official GitLab Community Discord
GitLab maintains an active Community Discord where coaches, Core Team members, and staff hang out.
-
Channel:
#contribute -
Format: Keep your message concise and transparent:
> "Hey everyone! I opened a community contribution MR:
<LINK_TO_MR>. Pipeline is green and ready for review. Could someone point me to the right reviewer/maintainer to tag? Thank you!"
6. Pro Tips for Smooth Approvals
- Keep MRs Small and Focused: An MR with 50 lines changed gets reviewed 10x faster than an MR with 500 lines touching 15 files.
-
Provide Clear Context: Fill out the MR description template fully. Include:
- What changed
- Why it was changed (link the issue)
- How to test it locally
- Screenshots/GIFs for UI changes
- Respect Timezones & Working Hours: GitLab is an all-remote, asynchronous organization spanning every timezone. Give reviewers at least 24–48 hours before expecting a response.
Top comments (0)