Contributor Success Team

Common Links

Sub-pages

Strategy

This team directly follows the strategy outlined in our open source growth strategy.

Mission

The goal of the team is to lead the contributor program, support & attract customers who co-create GitLab with us and increase the efficiency of our contribution process through technical and process improvements to sustain our ambition of 170+ contributors with merged MRs per month to GitLab. This is aligned with GitLab’s mission to enable everyone to contribute to and co-create the software that powers our world and is aligned with the 3-year internal company strategy.

FY26 Direction

In FY26 we will be continue our focus on the following key initiatives

• Increasing MRARR through our GitLab co-create program. Aligned with our value results for customers
• Growing the number of unique new monthly contributors, code and non-code. Aligned with our open source growth strategy
• Reducing Open Community MR Age (OCMA). Aligned with our open source growth strategy
• Shifting the focus towards higher valued contributions aligned with our product roadmap. Aligned with our open source growth strategy

As an internal priority we’ll focus on improving project & issue scoping and prioritization per the FY25Q3 retrospective.

Any engineering work required to reach these goals is within limits. For example, GDK work, POC’s of Duo, Triage-ops refactors with AI assisted classifications and more.

Unique New Monthly Contributors

1. Minimize reliance on human interaction
2. Reduce volatility through introducing automations that drive contributions forward automatically
3. Capitalize on untapped potential - MRs that have become stale but have received a seal of approval as useful addition to GitLab.
4. Invest into attracting more new contributors

Open Community MR Age (OCMA)

1. Minimize reliance on human factors that contribute to a large standard deviation
2. Identify & drive tooling improvements to decrease OCMA

Co-Create

The GitLab Co-Create program is a cross-functional initiative that is led by the Contributor Success team, in combination with Product & Engineer. More GitLab specific instructions can be found in our cocreate handbook page.

Team Responsibilities

• Improve GitLab’s Contribution Efficiency and merge request coaching process.
• Contribute as a merge request coach in one or more specialties by providing guidance to community contributors on technical and non-technical aspects.
• Be a point of escalation for community contributors and identify GitLab DRIs to resolve blockers.
• Organize community contributors into community teams and ensure their success.
• Track contribution delivery of the Community Contributors and Cohorts.
• Nominate impactful community contributors and contributions for recognition.
• Select and recognize a GitLab Notable Contributor for each release post
• Collaborate closely with our Marketing counterparts and Core team.
• Improve community recognition system, awards and engineering assistance in collaboration with the Developer Relations team.
• Participate in GitLab’s overall open source outreach events and processes.
• Triage community issues to be picked up by the community or GitLab team members
• Triage community merge requests from the daily merge request coach report
• Review merge requests assigned as a merge request coach or from the reviewer roulette

Team Members

Name	Role
Arianna Haradon	Senior Fullstack Engineer
Daniel Murphy	Senior Program Manager, Contributor Success
Lee Tickett	Fullstack Engineer, Contributor Success Core Team member
Nick Veenhof	Director, Contributor Success
Raimund Hook	Staff Fullstack Engineer, Contributor Success
Rostyslav Safonov	Fullstack Engineer, Contributor Success

Contributor platform

Our contributor platform is the central hub for open source contributors to GitLab and community activity. It consumes contribution data from multiple platforms and is fully documented in the contributors-gitlab-com project README.

@daniel-murphy is the product DRI and @leetickett-gitlab is the technical/engineering DRI.

File an issue

gitlab-org/gitlab

All issues that relate to the Open Source project GitLab and that can serve to enhance the contributor flow and are public by nature should be created here by default. We aim to not have any distinction between contributors or GitLab team-members for which we expect by default that everyone should be able to contribute to.

• Location: gitlab-org/gitlab
• Required label: Contributor Success

gitlab-org/developer-relations/contributor-success/team-task

All issues that relate to the inner working of the company GitLab, including specific internal team workings, onboardings-issues or issues relating to customers that should be separated from the Open Source project GitLab can be placed here.

• Location: gitlab-org/developer-relations/contributor-success/team-task
• Required label: Contributor Success

Project Management

• Our team project is our single source of truth for all tasks & backlog.
• Epics that contain cross-functional work across multiple departments can be created at the gitlab-org level.

OKRs

OKRs are not public. But rest assured, we have these goals always in mind, including in our quarterly objectives & key results.

Performance Indicators

We have the following Performance Indicators

Unique Wider Community Contributors per Month

Unique Wider Community Contributors per Month

• Activities:
  • Partnership with Developer Relations team.
  • Hold community office hours.
  • Hold hackathons.
  • Allow running of QA tests from forks.
  • Shorten the CI runtime for community contributions (in forks).

More details can be found in the Unique Wider Community Contributors per Month Marketing PI section

Open Community MR Age (OCMA)

• Activities:
  • Shorten CI time
  • Improve Community Contribution automation
  • Enable running QA tests on forks
  • Increase number of coaches
  • Partner with Engineering Productivity to provide feedback to improve contribution tooling (currently GDK).

More details can be found in the OCMA Developer Relations PI section

MRARR

• Activities:
  • Reach out to top tier enterprise customers
  • Help take-on inactive customer contribution to completion & merge
  • Partner with CSMs to enlist and facilitate contribution from customers
  • Launch contribution materials targeting large enterprises
  • Partner with Developer Relations team (David P)
  • Maintain a list of known contributors with a mapping to their accounts and the accounts ARR contribution as input to this KPI

Please see Contributing Orgs tracker for details how to onboard or offboard a GitLab account from being linked to a customer account, and being counted into the MRARR metric.

More details can be found at the MRARR Developer Relations PI section

How we plan work

The team uses the Contributor Success Kanban board. Issues must:

• Be created in the gitlab-org group
• Have the Contributor Success label
• Have at least 1 workflow label from the list below

We use priority labels to designate focus areas per quarter.

Workflow labels

• workflow::validation backlog: Issues start in our backlog so the team can validate for effort vs. impact against our KPIs, OKRs and team strategies.
• workflow::refinement: These issues are validated and refined through planning and team discussion before they are marked as ready. Issues should have an Implementation Plan section before moving to the next workflow stage.
• workflow::ready for development: These issues are ready to be picked up, have an Implementation Plan section and a priority label.
• workflow::in dev: Issues actively being worked on this quarter.
• workflow::blocked: Issues currently blocked. The description must note the blocker and include a link to issues that would unblock.
• workflow::complete: Issues that are resolved after implementation. These should be highlighted in reports back to the team and DevRel department before being closed.

Priority labels

• priority::1 (highest priority): Issues critical to the current quarter’s KPIs and OKRs, or urgent bugs blocking work for contributors.
• priority::2: Issues aligned with current quarter’s goals but without urgent due dates.
• priority::3: Issues that support long-term objectives without impact on current quarter goals.
• priority::4 (lowest priority): Issues that bring incremental value but can wait for additional capacity.

How to pick issues

Team members should select issues from workflow::ready for development based on priority label. While the team focuses on priority::1 and priority::2 issues for the current quarter, sometimes it makes sense to pick up a lower-priority task between larger projects. We are guided by GitLab’s values on efficiency and iteration to act as managers of one when choosing tasks.

Contributor Success Retrospective

Every quarter we hold an asynchronous retrospective (example) using GitLab issues.

Questions asked are

• What should we start?
• What should we stop?
• What should we continue?

Contributor Success’ DRI is responsible for creating an issue in the team tracker gitlab-org/developer-relations/contributor-success/team so that it can be easily retrieved in the future.

Contributor Success’ DRI is responsible for digesting the feedback and selecting one, after votes, issue to take into the new quarter.

Contributor Success stand-up

The purpose of this stand-up is to collaborate between teams members of Contributor Success. This is a team-specific meeting to check in on blockers, progress and ways to think differently & iterate towards our goals.

• Agenda: https://docs.google.com/document/d/1chIzCdg1CNRrRRuYR7c7OW_BF1mBxKFTJoXyP2HLt4E/edit#heading=h.o6qzal1u0b7i

Contributor Success reading list

A curated list of external resources for improving open source community relations and the contributor experience:

• Diversity, Equity, and Inclusion in Open Source
• Working in Public: The Making and Maintenace of Open Source Software
• Growing Your Contributors
• Building Welcoming Communities
• Open Source Survey
• Non-code contributions are the secret to open source success
• The secrets to onboarding new open source contributors
• The privilege of free time in Open Source
• Good first issues don’t exist

Promotion

We recommend adding an event to the GitLab Team Meetings calendar (internal) and creating:

• An event in the GitLab Virtual Community Events meetup group.
• An event on the GitLab Community Discord.
• An agenda (using Google Docs, with public editor access so everyone with the link can collaborate).

NOTE: Make sure Zoom links have the password embedded.

View page source - Edit this page - please contribute.