At the recent GitLab Meetup in Hamburg, we explored how easy it is to make your first contribution to GitLab. The session combined discussion, practical guidance, and a live demo where we contributed together.
Contributing to GitLab is not only a great way to learn, but also a way to make the tool better for everyone. During the session, we covered the following resources to help new contributors get started:
To make your first steps easier, GitLab also provides a list of issues labeled “quick win”. To start, we recommend looking at simple refactoring issues regarding the vue/no-unused-properties violations. These are well-suited for first-time contributors who want to dive into real code.
For our hands-on demo, we picked a simple first-time-contributor Issue #525766 regarding the vue/no-unused-properties violations. For demonstration purpose, we fixed the violation just for one file and created a Merge Request together. The merge request is already under review, showing how quickly a contribution can move forward.
Each contribution — large or small — helps make GitLab better. If you’re curious, try out the guides above, pick an issue, and create your first merge request. The 🦊 community is always ready to support you.
On average, how fast are contributions merged? On what does it depend?
The timeline varies by change size and complexity. Small “quick win” MRs often get reviewed and merged within a few days to a week, depending on reviewer bandwidth, test results, and whether revisions are requested. The more complex the MR is, the longer it takes to review because more people are involved.
What are the GitLab style guides, and do I need to actively follow them?
GitLab maintains style guidelines for code and documentation—see the GitLab documentation style guide. You don’t need to master everything before you start. Git provides commit and pre-push hooks that run local checks and catch obvious issues before your changes go up; the final validation happens in the CI/CD pipeline on your merge request. As a beginner, rely on these hooks and pipeline feedback, then fix what they flag. This lets you make progress without reading all the documentation up front.
