My First GitLab Hackathon: From 357 Issues to 20 Merge Requests on Day One

This week is my first GitLab Hackathon (October 6 to 12, 2026). It's a week-long online event where anyone can contribute to GitLab's own projects: code, docs, tests, translations, and more. Every merge request (MR) you open during the week earns points, and it earns a lot more if it gets merged within 31 days.

I'm writing this on the evening of day one. So far I have 20 MRs open, 6 approved, and 1 already merged. This post covers how I got ready, what day one actually looked like, and the mistakes and surprises along the way.

How I got here

I've been taking part in hackathons on Devpost for a while. A few months ago I saw GitLab's Transcend hackathon there and made a GitLab account for it, but I was short on time and couldn't take part. A few weeks ago I started looking for a way into open source, and remembered I already had that GitLab account. I started with a few small docs fixes, and that's how I found out about GitLab's community hackathon.

I made my first GitLab contribution on September 21, 2026, a small fix to the GitLab CLI. Over the next two weeks I got 12 MRs merged across gitlab-org/gitlab, the CLI, and the Pajamas design system. That was enough to understand how GitLab reviews work: bots assign reviewers, a reviewer checks the change, and a maintainer merges it.

It also taught me the most important thing for the hackathon: finding the right issue takes longer than fixing it.

Preparation: the day before

1. Read the rules first

The hackathon rules are short, and every one of them matters:

• Accept the rules on the hackathon page, or you get no points at all.
• Get assigned to an issue (through the contributor platform) before you open an MR for it.
• Put Closes #<issue> in the MR description. A merged MR linked to an issue earns 30 extra points.
• At most 20 MRs per day, and only one typo-fix MR per project.
• AI tools are allowed, but you're responsible for everything you submit.
• If none of your MRs get merged within 31 days, you get zero points.

2. Check a lot of issues

GitLab labels issues that are good for community contributors (quick win, Seeking community contributions, and similar). I went through 357 open issues with these labels and checked each one against the latest master branch.

Only 98 were ready to pick up. The rest:

• 158 were not ready. They needed a design decision, domain knowledge, or input from the team first.
• 69 were stale. The bug was already fixed on master, or the code had changed so much that the issue no longer made sense.
• 32 were claimed. Someone was already working on them, often visible only in the comments, not in the assignee field.

Lesson: a quick win label doesn't mean the issue is still open for work. Always check master and read the comments before you start.

3. Pick, assign, and fix ahead of time

From the 98, I picked 22 with a clear fix and good chances of getting merged, and got assigned to them. They were a mix:

• 7 small frontend cleanups moving navigator.clipboard calls to GitLab's shared copyToClipboard helper
• other frontend fixes, like hiding the "Explain Code" button while blame info is shown
• backend bug fixes, like a 500 error in the resource access token API
• test improvements

Two of them dropped out before the start. One was already fixed on master (I left a comment so it could be closed), and another contributor already had an MR for the other.

For each issue I made a separate branch with the fix and ran the tests I could: Jest, ESLint, and Prettier for frontend changes. GitLab's backend test suite needs a full development environment, so for Ruby changes I could only run syntax checks and had to rely on CI. I also wrote three files per issue: the patch, the MR description, and a short notes file listing what a reviewer might push back on. Those notes turned out to be very useful on day one.

Day one: October 6

Opening was the easy part. The hackathon runs in UTC, so it started at 5:30 am in India. I accepted the rules, and at 9:30 am a small script opened all 20 MRs through the GitLab API in about five minutes. 20 is the daily limit, so that was my whole day's quota.

Then the GitLab bots took over:

1. Each MR got the Hackathon and Community contribution labels automatically.
2. Once the diff showed up, I commented @gitlab-bot ready on each one. This tells the bot the MR is ready for review.
3. Within ten minutes, every MR had a reviewer assigned.

The first approval came at 12:49 pm. At 3:04 pm, !259854 was merged, about five and a half hours after I opened it. By the evening, 6 MRs were approved and the CI pipeline was green on all 20.

Here are all 20:

MR	What it does	Area	Status (end of day one)
!259851	Migrate navigator.clipboard in code block bubble menu to copyToClipboard	frontend	in review
!259852	Migrate navigator.clipboard in link bubble menu to copyToClipboard	frontend	in review
!259853	Migrate navigator.clipboard in reference bubble menu to copyToClipboard	frontend	in review
!259854	Migrate navigator.clipboard in candidate detail to copyToClipboard	frontend	merged
!259855	Migrate navigator.clipboard in MLflow usage modal to copyToClipboard	frontend	in review
!259856	Migrate navigator.clipboard in ML model version page to copyToClipboard	frontend	in review
!259857	Migrate navigator.clipboard in work item actions to copyToClipboard	frontend	approved
!259858	Ignore OWASP identifiers in vulnerability deduplication	backend + docs	approved
!259859	Return false for URLs that cannot be parsed in isReasonableGitUrl	frontend	in review
!259860	Validate export prefix format on offline transfer configuration	backend	approved
!259861	Use stubbed records instead of doubles in CrossProjectReference spec	tests	in review
!259862	Guard local storage helpers with canUseLocalStorage	frontend	approved
!259863	Add Dedicated instance spec for POST admin registrations groups	tests	in review
!259864	Add Dedicated instance spec for PATCH admin registrations profile	tests	in review
!259865	Fix 500 error in resource access token API when bot has no membership	backend	approved
!259866	Hide Explain Code button while blame is shown in the blob viewer	frontend	in review
!259867	Exclude the moved secret when counting CI policy secrets	backend	in review
!259868	Attribute AI user metrics ClickHouse query to the root namespace	backend	in review
!259869	Remove safe navigation on request in MergeRequestBasicEntity	backend	in review
!259870	Show "Raw text search not supported" in repositories filter bar	frontend	in review

What the reviewers taught me

The reviews were the best part of the day. A few examples:

• Docs have to cover older versions too. For a docs issue I'm preparing (#606621), I planned to delete a section about an old limitation. A GitLab team member explained that GitLab 18.0 to 18.5 are still supported and still have that limitation, so the right fix is to update the section and say "In GitLab 18.6 and later". I hadn't thought about that at all.
• Show it working. On one frontend MR, the reviewer asked for a screenshot showing that the copy button still works. Tests prove the code path, but a screenshot lets a reviewer see it in a few seconds. Next time I'll add before/after screenshots to UI changes from the start.
• Check master again before you open. One of my older, non-hackathon MRs was closed because the same fix had landed on master while it waited for review.

Things that surprised me

• A shallow clone can't push to the community fork. GitLab's repository is huge, so I used a shallow clone. git push to the community fork kept failing, so I created every commit through the GitLab API instead.
• Pushing a new commit removes existing approvals. In gitlab-org/gitlab, any push to the MR branch resets approvals. Danger (GitLab's MR bot) warned that a few of my commit messages had lines over 72 characters, but fixing that would have cost me two approvals, so I left them. The MRs are squashed on merge anyway.
• The issue cap counts everything. The contributor platform limits how many open issues you can be assigned (16 at my level). It counts every open issue assigned to you in gitlab-org, including the rewards issue the platform creates when you level up. I hit the cap on day one. To free slots, close issues as their MRs merge, and close your rewards issue once you've seen it.
• Merged doesn't always mean closed. My merged MR said Closes #579486, but the issue stayed open. I closed it myself, which also freed a slot.

What I've achieved so far

• 20 MRs open in gitlab-org/gitlab, 6 approved, 1 merged on day one
• Reached level 3 on the contributor platform during day one
• A non-hackathon docs MR (!256715) that had been through two review rounds also got merged the same day
• A lot of lessons about how a big open source project actually reviews code

What's next

• Answer reviewer comments and get as many of the 20 merged as possible before the November 12 deadline
• Close each issue as its MR merges, to free slots for new ones
• Open the updated docs MR for #606621
• Try translating GitLab into Hindi on Crowdin. It's only about 2% done.

Tips for your first GitLab Hackathon

1. Prepare before day one. You can't open MRs early, but you can find issues, get assigned, and have your fixes ready.
2. Check every issue against master. About 1 in 5 of the issues I checked were already fixed or out of date.
3. Read the comments, not just the assignee field. Many issues are claimed in a comment.
4. Add Closes #N to every MR description.
5. Batch your fixes. Every push resets approvals, so make all changes from one review round in a single push.
6. Add screenshots to UI changes from the start.
7. Be honest about AI help. GitLab allows AI tools and holds you responsible for the result. I said so in every MR description.

Links

• GitLab Hackathon page and rules
• Contributor platform user guide, including how points work
• My GitLab profile and my merge requests
• GitLab Community Discord, the place to ask questions during the hackathon

---

I used an AI coding assistant to help sort through issues, prepare fixes, and draft this post. I reviewed and tested every change myself, and I take responsibility for all of it. The charts are made from my own notes and the GitLab API.

I'll post an update once the merge window closes. If you're taking part in this hackathon too, say hi in the comments.