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
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
Minimize reliance on human interaction
Reduce volatility through introducing automations that drive contributions
forward automatically
Capitalize on untapped potential - MRs that have become stale but have received a seal of approval as useful addition to GitLab.
Invest into attracting more new contributors
Open Community MR Age (OCMA)
Minimize reliance on human factors that contribute to a large standard deviation
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.
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.
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.
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.
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.
Below are email templates that can be used for communicating with community members. Whenever possible, it is strongly encouraged that each email message be customized for each individual & circumstance.
Outreach after the first merged MR
Directly via email
Hello NAME,
I'm reaching out to both thank and congratulate you on your first Merge Request (MR) to help improve GitLab. We appreciate everyone's effort to contribute to GitLab, especially when it's an individual initiative and we are blessed to have such a wonderful community.
I wanted to offer you a small token of our appreciation as you're getting started with your code contributions to GitLab. Please go to [URL] to submit your order for the latest GitLab mug with a special hashtag to celebrate your first merged MR. When you receive the merchandise, it would be great if you can make a post on twitter with your photo of the mug plus '@gitlab' & '#myfirstMRmerged' in the tweet.
Thanks again for your first MR to GitLab and welcome to the GitLab community!
Sincerely,
YOUR_NAME
As a comment on their merged MR
Hi there, and congratulations on having your first MR merged!
I want to offer you a small token of our appreciation as you're getting started with your code contributions to GitLab. Please fill [out this form](https://docs.google.com/forms/d/e/1FAIpQLSfGo-3kEimVPpC5zKKxXHkFjgYx8-vQAanzAX2LxGgXQqXikQ/viewform), and I will be reaching out with more information on how to receive your special #my1stMRmerged coffee mug.
Outreach to inactive contributors
Hello NAME,
I'm reaching out to you as we have not seen a merged MR from you since DATE. The GitLab community would not be the same if it weren't for contributors like you. If you haven't done so lately, you can look for issues that are "Seeking community contributions" as we would welcome your help on these.
Please let me know if you have any questions and I look forward to your continued involvement in the GitLab community.
Sincerely,
YOUR_NAME
We want to recognize amazing contributions from the wider community with GitLab swags.
All GitLab team members and members of the wider community are encouraged to nominate others or themselves (for campaigns such as #myfirstMRmerge).
Include Everyone
If you think that someone deserves a swag prize, nominate them!
If you reached an important campaign milestone (e.g. #myfirstMRmerged) with your contribution, you can also nominate yourself!
Create a new issue using the mr_coach_onboarding template (see screenshot below).
Fill in the placeholders in the issue template with your information.
Assign the issue to yourself.
Work through the steps in that new issue.
Stepping down gracefully
If you are no longer able to serve as a Merge Request Coach, you should identify another GitLab team member to take your place so that the capacity of the remaining coaches remains the same. When you are ready to step down, you need to: