DEV Community

Pavan Kumar Sadashiv
Pavan Kumar Sadashiv

Posted on

The Fast-Track Playbook to Becoming a GitLab Core Contributor

#gitlab #opensource #career #programming

The Fast-Track Playbook to Becoming a GitLab Core Contributor

Contributing to a multi-million-line enterprise codebase like GitLab can feel intimidating at first glance.

Between the monolithic Ruby on Rails backend, Vue.js frontend, Python-powered AI Gateway, hundreds of microservices, and extensive CI/CD verification matrices, it is easy for developers to feel overwhelmed before opening their first pull request.

However, GitLab has one of the most organized, supportive, and rewarding open-source contributor programs in the entire tech industry: the GitLab Contributor Platform (contributors.gitlab.com).

Recently, through contributing to GitLab Core (implementing Model Context Protocol resources in MR !260212) and the AI Gateway (MR !7251), I learned the exact patterns that help you go from zero to your first merged MR quickly and painlessly.

Here is the exact playbook to kickstart your journey.

1. Finding the Right Issue: The Label Secret

The biggest mistake new contributors make is browsing thousands of unassigned issues randomly.

GitLab uses a disciplined issue labeling system. To find issues designed specifically for community members with active maintainer mentorship, filter by these exact labels:

Label What It Means Best For
quick win Isolated tasks with clear acceptance criteria and minimal dependencies. First-time contributors.
community contribution Open to external contributors; maintainers actively monitor and review. General development.
community-bonus::100 / ::200 High-priority issues with extra contributor reward points attached. Serious contributors.
Hackathon Issues tagged for GitLab’s quarterly community hackathon. Earning swag & tier ranks.
good for new contributors Guided issues often with hints in the issue description. Learning the workflow.

How to Filter:

Go to gitlab.com/gitlab-org/gitlab/-/issues and apply:

Label = "quick win" AND Label = "community contribution" AND State = "opened"
Enter fullscreen mode Exit fullscreen mode

Once you find an interesting issue, leave a polite comment on the issue thread:

"Hi @maintainer, I'd like to work on this issue. Could you please assign it to me?"

2. Setting Up Your Development Environment

You don't need a massive workstation to contribute to GitLab. You have three primary development paths:

Option A: GitLab Gitpod / Web Workspaces (Zero-Install)

For quick documentation, frontend, or minor backend adjustments, open any repository in Gitpod or a GitLab Web IDE workspace. The dependencies and environment are pre-provisioned in the cloud.

Option B: GitLab Development Kit (GDK)

If you are developing deep backend features in GitLab Core:

# Clone and install GDK
git clone https://gitlab.com/gitlab-org/gitlab-development-kit.git
cd gitlab-development-kit
gdk install
gdk run
Enter fullscreen mode Exit fullscreen mode

Option C: Microservices & AI Gateway (Python / Docker)

For microservices like GitLab AI Gateway (gitlab-org/modelops/.../ai-assist), setup is as simple as:

poetry install
poetry run pytest tests/
Enter fullscreen mode Exit fullscreen mode

You don't need to boot the full Rails stack to contribute to the AI Gateway or documentation.

3. Navigating the CI Pipeline Like a Pro

When you open a Merge Request (MR) in GitLab, an automated pipeline triggers. Here is how to pass the most common gates on your first try:

1. Danger Bot

Danger checks automated hygiene rules:

  • Did you add a changelog entry? (Create a small YAML file in changelogs/unreleased/).
  • Did you adhere to commit title conventions? Use imperative mood: Add resources handler for MCP.
  • Did you tag the right stage / group label (e.g., feature_category: :ai_abstraction)?

2. RuboCop

GitLab has custom RuboCop rules. Run it locally before pushing:

bundle exec rubocop path/to/your/file.rb
Enter fullscreen mode Exit fullscreen mode

If you encounter style complaints, run rubocop -a to auto-correct standard formatting.

3. Predictive RSpec

To save CI minutes, GitLab uses predictive testing to run only the tests related to your changes. Make sure your local unit test passes:

bundle exec rspec spec/lib/your_feature_spec.rb
Enter fullscreen mode Exit fullscreen mode

4. The Review Process & Code Etiquette

GitLab uses GitLab Duo Code Review and Reviewer Roulette to assign your MR to a coach or maintainer.

Tips for Fast Approvals:

  • Keep MRs Focused: One problem per MR. If you find unrelated refactoring opportunities, open a separate issue.
  • Explain the "Why": In your MR description, link the issue (Closes #12345), explain what changed, and paste before/after terminal outputs or screenshots.
  • Be Responsive: If a maintainer leaves a suggestion, address it promptly or explain your architectural reasoning politely.

5. Earning Recognition: The Contributor Platform

Your contributions don't stop with git commits. GitLab recognizes community participation on contributors.gitlab.com:

  • Merged Code / Bug Fixes: Automatically credit points based on complexity and bonus tiers.
  • Content Publication (200 pts): Writing tutorials, blog posts, or walkthroughs about your contribution.
  • Event Engagement (500 pts): Speaking at meetups, hosting tech talks, or demoing GitLab features.

These points accumulate toward community tiers, exclusive contributor swag (jackets, backpacks, mugs), and invitations to GitLab events.

6. Summary Checklist for Your First Contribution

  • [ ] Register on contributors.gitlab.com.
  • [ ] Find an issue with quick win or community-bonus.
  • [ ] Request assignment in the comments.
  • [ ] Fork the repo and create a feature branch (git checkout -b fix-issue-xyz).
  • [ ] Write the fix + unit test.
  • [ ] Run linters locally (rubocop, ruff, or markdownlint).
  • [ ] Open your MR with a clear description and Closes #XYZ.
  • [ ] Address review feedback.
  • [ ] Celebrate your merge and share your learning with the community!

Resources

Have you made your first open-source contribution yet? What is holding you back? Ask your questions in the comments!

Top comments (1)

Collapse
 
nicholasflemmer profile image
Nic Flemmer •

The part about passing CI before asking for review is the bit most first-timers skip, so it's good to see it spelled out. If you want something smaller than GitLab to practise on, Styx (my open-source desktop app) has #33, a TypeScript fix where a config key is read that nothing writes any more. There's a guide, and issues get a reply within 2 working days.