How we use GitLab to grow open source communities

GitLab's Contributor Success team faced a challenge.

While our returning open source contributors were merging more code changes and collaborating on deeper features, first-time contributors were struggling to get started. We knew many newcomers to open source often gave up or never asked for help. But as advocates for GitLab's mission

to enable everyone to contribute, we wanted to do better.

We started running research studies on open source contributors to GitLab. Then we improved the stumbling blocks. In January, we achieved a record of 184 unique community contributors to GitLab in a single month,

exceeding our team target of 170 for the first time.

Three months later, we broke it again with 192.

Here's how we used GitLab's own tools to solve the newcomer dilemma and grow our open source community.

What we learned studying first-time contributors

In 2023, we conducted the first-ever user study of GitLab open source contributors.

We watched six participants who had never contributed to GitLab make their first attempt. They completed diary studies and Zoom interviews detailing their experience.

Participants told us:

• The contributor documentation was confusing

• Getting started felt overwhelming

• It wasn't clear how or where to find help

Only one out of the six participants successfully merged a code contribution to GitLab during the study.

It became clear we needed to focus on the onboarding experience if we wanted new contributors to succeed.

So we iterated!

Our team spent the next year addressing their challenges. We used GitLab tools,

such as issue templates, scheduled pipelines, webhooks, and the GitLab Query Language (GLQL), to build an innovative semi-automated onboarding solution.

In 2025, we performed a follow-up user study with new participants who had never made a contribution to GitLab. All 10 participants successfully created and merged contributions to GitLab, a 100% success rate. The feedback showed a great appreciation for the new onboarding process, the speed at which

maintainers checked in on contributors, and the recognition we offered to contributors.

Even better, participants shared how much fun they had contributing:

"I felt a little rush of excitement at being able to say 'I helped build GitLab.'"

We built personal onboarding with GitLab

Our solution started with engagement.

To help newcomers get started, we introduced a personal onboarding process connecting each

contributor with a community maintainer.

We created an issue template with a clear checklist of tasks.

The onboarding issue also handles access approval for the

GitLab community forks,

a collection of shared projects that make it easier to push changes, collaborate with others,

and access GitLab Ultimate and Duo features.

Using scoped labels, we indicate the status of the access request for easy maintainer follow-ups.

We started with a Ruby script run via a scheduled pipeline,

checking for new access requests and using the issue template to create personalized onboarding issues.

From here, our maintainers engage with new contributors to verify access, answer questions, and find issues.

We standardized responses with comment templates

With multiple maintainers in the GitLab community, we wanted to ensure consistent and clear messaging.

We created comment templates,

which we sync with the repository using the GraphQL API and a

Ruby script.

The script is triggered in .gitlab-ci.yml when comment template changes are pushed

to the default branch (a dry run is triggered in merge requests).

execute:sync-comment-templates:
  stage: execute
  extends: .ruby
  script:
    - bundle exec bin/sync_comment_templates.rb
  variables:
    SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_ONLY
  rules:
    - if: $CI_PIPELINE_SOURCE == 'schedule' || $CI_PIPELINE_SOURCE == "trigger"
      when: never
    - if: $EXECUTE_SYNC_COMMENT_TEMPLATES == '1'
    - if: $CI_MERGE_REQUEST_IID
      changes:
        - .gitlab/comment_templates/**/*
      variables:
        REPORT_ONLY: 1
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      changes:
        - .gitlab/comment_templates/**/*
      variables:
        FORCE_SYNC: 1
        DRY_RUN: 0
        SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_WRITE

We eliminated the 5-minute wait time

Our first iteration was a little slow.

After starting the onboarding process, contributors wondered what to do next while the scheduled

pipeline took up to 5 minutes to create their onboarding issue.

Five minutes feels like forever when you have the momentum to dive in.

Niklas, a member of our Core team , built a solution.

He added webhook events for access requests

and custom payload templates for webhooks.

These features together allowed us to trigger a pipeline immediately instead of waiting for the schedule.

This reduces the time to roughly 40 seconds (the time it takes for the CI pipeline to run)

and generates the onboarding issue right away. It also saves thousands of wasted pipelines and compute minutes when no access requests actually need processing.

We set up a pipeline trigger token

and used this as the target for the webhook, passing the desired environment variables:

{
  "ref": "main",
  "variables": {
    "EXECUTE_ACCESS_REQUESTS": "1",
    "DRY_RUN": "0",
    "PIPELINE_NAME": "Create onboarding issues",
    "GROUP_ID": "{{group_id}}",
    "EVENT_NAME": "{{event_name}}"
  }
}

We automated follow-ups

With an increasing volume of customers and community contributors onboarding to the GitLab community,

maintainers struggled to track which issues needed attention and some follow-up questions got lost.

We built automation leveraging webhooks and Ruby to label issues updated by community members.

This creates a clear signal of issue status for maintainers.

GitLab Triage

automatically nudges idle onboarding issues to ensure we maintain contributor momentum.

We organized issue tracking with GLQL

We built a GLQL view to keep track of issues.

This GLQL table summarizes onboarding issues which need attention,

so maintainers can review and follow up with community members.

These GLQL views improved our overall triage efficiency.

It was so successful we ended up using this strategy within the GitLab for Open Source

and GitLab for Education programs, too.

With GLQL tables for support issues, these community programs lowered their response times by 75%.

We made the README findable

The @gitlab-community group

is the home for contributors on Gitlab.com.

We already had a README.md file explaining the community forks and onboarding process, but this file

lived in our meta project.

With our follow-up user study, we discovered this was a point of confusion for newcomers when their

onboarding issues were under a different project.

We used GitLab's project mirroring

to solve this and mirrored the meta project to gitlab-profile.

This surfaced the existing README file at the group level, making it easier to discover.

The results speak for themselves

By dogfooding GitLab, we improved the stumbling blocks found in our research studies

and transformed the GitLab contributor journey.

We have grown the number of customers and community members contributing to GitLab,

adding features to the product, solving bugs, and adding to our CI/CD catalog.

Our onboarding process has increased the rate newcomers join the community, and our total number of

contributors on the community forks has doubled over the last 9 months.

We reduced the time it takes for newcomers to make their first contribution by connecting them

with maintainers faster and supporting them in getting started.

We use GitLab's value stream analytics

to track our response rates.

• First response time from community maintainers is down to 46 minutes over the last 3 months

• Average approval time for community forks access is down to 1 hour over the last 3 months

The 100% success rate of our 2025 user study confirmed these improvements for our first-time contributors.

We invested time savings into contributor recognition

Fixing these newcomer challenges allowed us more capacity to focus on better recognition of

contributors, incentivizing first-timers to keep coming back.

The result is contributors.gitlab.com.

We built out a central hub for our contributors that features gamified leaderboards,

achievements, and rewards.

Contributors can see their impact, track progress, and grow in the community.

Sharing what we learned

These improvements work and are repeatable for other open source projects.

We are sharing our approach across communities and conferences so that other projects can consider using these tools to grow.

As more organizations learn the barriers to participation, we can create a more welcoming open source environment.

With these GitLab tools, we can offer a smoother experience for both contributors and maintainers.

We're committed to advancing this work and collaborating to remove barriers for open source projects everywhere.

Start the conversation

Want to learn more about growing your contributor community?

Email [email protected] or open an issue

to start a discussion.

We're here to help build communities.