From Aiming for 1st to Winning 2nd: My GitLab Hackathon Experience
Introduction
In the previous article, I told you about my experience as a notable contributor for GitLab in the 18.5 release. In this article, I will tell you about my experience in the GitLab Hackathon, an event held every three months that seeks to get the largest number of contributors to participate and provide real value to GitLab.
Competition Format
The Hackathon rules are simple: you earn points for each merged Merge Request, and if the Merge Request has a linked issue, you earn more points. The duration of the Hackathon is one week, during which you can create the Merge Requests. But after that week ends, you have one more month to work on those MRs until they are merged. After this time limit passes, the points are counted, and the winners are announced.
My Goal
I am a very competitive person, so honestly, my goal was to win the Hackathon. By the time the Hackathon started, I had already been contributing to GitLab for a while, so I was familiar with the process and had identified the repositories where I could make a difference, all related to Golang because at that time I had no experience with Ruby (something that has slowly changed). These repositories were mainly, client-go and terraform-provider.
Strategy
The Hackathon started on a Wednesday, and since I have to manage my time well due to my full-time job as a Software Engineer, I started working on the weekend on the MRs I was going to create on Wednesday so they would count for the Hackathon. I remember I had about 7 MRs ready from the moment the Hackathon began thanks to this strategy. This way, I could manage to fulfill my work responsibilities and also participate in the Hackathon. Most of these MRs were new integrations for the GitLab API Go client and refactors or bug fixes in the Terraform provider. Since I knew I would have strong competition from other contributors, I also considered making documentation MRs, which are very easy to do and can add up points quickly.
My goal was never to win the Hackathon based on documentation MRs; I always wanted to generate real value with my contributions. But it doesn’t hurt to have this as an alternative to score points.
The Unexpected
For most of the Hackathon, I was in first place, but in the last two days, I started to see contributors gaining a large number of points quickly just by making documentation MRs. This bothered me at first because I personally don’t see it as right, but it also put my first place at risk. Because of this, to not lose my top spot, I started doing the same (which was truly my mistake). A Hackathon contestant complained about this, and GitLab made the decision to only count one of these MRs per participant. Meaning, if you had made 10 of these simple MRs, only one would count.
I think it was the right decision to make it a fair competition, but honestly, it would have been good to know this from the beginning, mainly because in that case, I wouldn’t have been distracted by contributors gaining points just by making documentation MRs.
Final Result
Finally, yesterday the Hackathon winners were announced, and I won 2nd place. Despite not winning 1st place, I consider it a very good result, as I have the satisfaction of having contributed real value to GitLab, and this is reflected in my being named a notable contributor in the 18.5 release. I plan to continue participating in future GitLab Hackathons, and my goal will continue to be aiming for 1st place.
See you soon
If you are interested in this type of article and want to know more about my experience as a GitLab contributor, don’t forget to subscribe to my newsletter using the form at the end of the article. I will soon publish other articles about GitLab, specifically about the prizes I have gotten from the rewards store.