The GitLab Hackathon ended on October 12, and that's a wrap for me. 🎉 On day one I wrote about getting 20 MRs open before lunch. This is the rest of the story: the whole week, what reviewers taught me, and one thing I got wrong on the last day.
From here on I'm not opening anything new. I'm just answering reviews until my open MRs get merged.
The week in numbers
- 91 merge requests opened during the event
- 38 merged so far, 51 still in review, 2 closed
- 30 different GitLab projects
- Fastest merge: about 28 minutes (charts!5467, a docs link fix). The median was about a day.
The shape of the week wasn't planned. Day one used the full limit of 20. On day two I didn't open anything new, because reviews started coming in and fixing review comments felt more important than opening more MRs. Thursday, Friday and Monday were big days again, and I took Sunday off.
Moving past the main app
On day one, all 20 MRs went to gitlab-org/gitlab, the main GitLab app. That repo is huge, and a lot of community contributors are working in it at the same time. One of my MRs became a duplicate when someone else's fix for the same issue merged first, and on another issue a second contributor opened their own MRs the same morning.
So from day three I looked at GitLab's other projects: the CLI, the Go API client, the Helm charts, Gitaly, the GDK, the docs site, the ESLint plugin, small Ruby gems, and more. They get fewer contributors, the issues are less picked over, and the reviewers have more time per MR.
Most of those MRs are small: dead links, outdated docs, a missing README section, a confusing error message, a lint rule turned on. Nothing fancy, but every one fixed something a real user or contributor would trip over.
What reviewers taught me this week
The reviews were the best part again. Some things I'll take with me:
Show that it works, even when nothing changes visually. On a frontend cleanup MR, the reviewer was happy with the code but asked me to prove the copy button still worked and to add testing steps. Tests prove the code path; testing steps let the next person check it in a minute.
Every project has its own rules. One project rejected my review-fix commit because its message didn't follow Conventional Commits (docs: ...). Another needed a type:: label before its pipeline would pass. Another flagged a missing changelog trailer on my commit. Reading CONTRIBUTING.md first saves a round trip.
Fork pipelines fail for reasons that aren't yours. When you contribute from a fork, some CI jobs can't get the tokens or runners they need: Danger has no API token, a publish dry run has no npm token, a docs lint can't download an artifact. Those failures aren't your bug, but they still block the merge, so a maintainer has to run the pipeline in the main project. One maintainer even recreated my MR in the main project to get it through. Explaining this politely in a comment, with the exact job and reason, helped a lot.
Close your own loops. My own @gitlab-bot ready comment opened a thread, and unresolved threads block merging. I had to go back and resolve it on 20 MRs. 😅 Also, a merged MR doesn't always close its issue, so I closed those myself, which also freed slots on the contributor platform.
Ask for reviewers the right way. I was pinging people directly at first. A coach pointed me to the contributor platform, where you can request a reviewer for your MR. That's the proper way, and it doesn't bother people who aren't the right fit.
Reviewers pass MRs along, and that's normal. Lots of reviewers said "this is outside my domain" and handed the MR to someone else. That isn't a no; it's how the MR finds the right person.
And sometimes a review is just nice to read:
That second one is !259865, the fix for a 500 error in the resource access token API. It took a week and a discussion about whether the change was a breaking API change before it got approved and merged. It was worth the wait.
Triage work
Besides MRs, I went through old issues that looked already fixed on master. For each one I checked the code, then left a comment with the proof (the commit or MR that fixed it) and asked if it could be closed. I posted 28 of these over the week, at most 5 a day, so maintainers wouldn't get flooded. Several of those issues were closed after maintainers checked them.
The mistake I made
This part isn't fun to write, but it's part of the week, so here it is.
On the last morning I used a script to add type and subtype labels to issues through the contributor platform. The platform has a labeling feature that earns a point per issue, and I treated it as a task to automate. Over about three hours the script labeled around 1,180 issues.
That was wrong. The labeling feature is meant for people labeling issues they work on, or the occasional untriaged issue, by hand. GitLab already has its own labeling automation, and every label from the platform posts a public comment, so my script created a lot of noise for the people who triage those issues. A GitLab team member flagged it and removed my labeling access, which stopped the script. I haven't run it or anything like it since. I posted a note explaining what happened, and told the organizers I'm fine with all of those points being removed and will accept whatever they decide.
The lesson for me: just because a points system rewards something doesn't mean anyone wants a thousand of it. Before automating anything on someone else's project, I'll ask myself whether a maintainer would want it done at that scale. If I'm not sure, I'll ask first.
What I didn't get to
In the day-one post I said I wanted to try translating GitLab into Hindi on Crowdin. I've dropped that for now. Doing it well takes real time and care, and right now my time is better spent getting the open MRs merged.
What's next
- Answer every review and get as many of the 51 open MRs merged as possible before the November 12 deadline
- Open the two follow-up MRs I promised reviewers on day two, once I'm assigned to their issues
- Keep contributing after the hackathon, just at a calmer pace 🙂
Tips if this is your first GitLab Hackathon
-
Look beyond
gitlab-org/gitlab. The smaller projects need help too, and there's less competition. -
Read each project's
CONTRIBUTING.mdbefore opening anything. Commit format, labels and changelog rules differ. - Fix review comments before you open more MRs. A merged MR is worth far more than an open one.
- Use the contributor platform to request reviewers.
- Resolve your own threads, and close issues your merged MRs fixed.
- Don't automate anything that touches other people's issues. If in doubt, ask in Discord first.
Links
Thanks to every reviewer and maintainer who took the time to look at my MRs this week. 🙏 If you took part too, I'd love to hear how your week went.
Top comments (0)