A GitLab contributor room is available on Discord for people interested in contributing to GitLab. This is open to everyone to join and is a good place for community members to network and help each other.
See the partial issue triage checklist.
Wider community merge requests are MRs opened by a person that's not present on https://about.gitlab.com/company/team/ (excluding any bot, service account users or individual contractors).
Community contribution label is automatically applied by the GitLab Bot to MRs submitted by wider community members.
gitLab-org list of merge requests.1st contribution label is added to first-time contributions. Every time a contributor is opening a merge request under the gitlab-org namespace for the first time, the label 1st contribution is automatically applied to the merge request.
gitlab-org list of merge requests.See Community-related triage reports.
See Community-related scheduled workflow automation.
See Community-related reactive workflow automation.
Merge request coaches are available to help contributors with their MRs. This includes:
coach will finish label will be added to the MR and the coach will either directly push new commits to the MR, or re-create a new MR with the original changes.@gitlab-org/coaches.The list of current merge request coaches can be found in the team page by selecting Merge Request
Coach in the department filter.
There is also the #mr-coaching channel in GitLab Slack if GitLab team
members have any questions related to community contributions.
More information on merge request coaches (including how to become a merge request coach) can be found in the MR coach lifecycle page.
For community contributors to contribute to the GitLab Enterprise Edition, they will need a license for EE. If they don't already have a license, they can get a free trial for 30 days (choose the Self-Managed option). If they cannot complete their work in 30 days, a new EE license for 90 days for a limited number of users (100) can be issued.
Renewal of this license:
Contributors will need to create an request in this project to request their license: Wider Community Contributor License Request.
(Internal link for GitLab team members) Upon evaluation of the contributor's request, a license request can be made using this form (Make sure to follow the Zendesk Global Light Agent steps if you haven't already). The Support team will respond following this workflow.
All external contributions to GitLab are subject to the GitLab DCO or CLA, depending on where the contribution is made and on whose behalf.
Instructions for corporate contributors to enter into an overarching Corporate CLA covering all contributions made on their behalf are set out on the DCO-CLA page.
Contributor success has been assisting the Legal and Corporate Affairs team with the creation and maintenance of a namespace under which GitLab can maintain lists of users associated with Corporate CLAs.
This group can be found here: https://gitlab.com/gitlab-corporate-cla
Adding a new corporate group under this namespace is as follows:
Private.Approved contributors for XXXXX under the GitLab Corporate CLA to the group description.Owner. (under Subgroup information > Members)Membership = Direct, click the 'kebab menu', select 'Leave Group')Caution: If an organization reaches the threshold it will be auto-enrolled in the program for receiving the review-time SLO.
See GitLab MVP Selection Process.
The Contributor Success team has been regularly thanking GitLab team members and Wider community members for active participation in Merge Requests. At the moment, this takes the form of:
#thanks channel in slack - Thanking GitLab team members for participation in Community Contribution Merge Requests.#thanks channel in discord - Thanking Wider community members for active participation in MRs that aren't their own.These messages are generated with the help of a script that is being maintained and iterated on by the Contributor Success Team.
This script can be executed on any machine by following these steps:
main branch of the toolbox project: git clone git@gitlab.com:gitlab-org/community-relations/contributor-success/toolbox.gitcd toolboxbundle installThis is typically done at some point on a Monday, but could be done on a Tuesday if the Monday is a holiday, or other day off. Regardless of the day it is sent, it is typically generated to cover the period of 7 days from the previous Monday.
To generate the internal weekly message:
#thanks in slack, taking care to note the keystrokes: Paste this message into slack using Cmd-v, then apply formatting using Cmd-Shift-F@ mentions where slack has 'helpfully' incorrectly linked the user.This message is typically sent within a day or two of a GitLab release (22nd of the month). It covers the time period between releases.
To generate the external community message:
#thanks in discord.Once posted to discord, you can post this message on the forum, too, under the Community category, with the addition of a crosslink to the Discord post. Forum posts can be deep linked to from social media, and additionally can be indexed by search engines.
@gitlab (note: never share a Zoom link on Twitter)There will be a quarterly Hackathon for GitLab community members to come together to work on merge requests, participate in tutorial sessions, and support each other on the GitLab Discord. Agenda, logistics, materials, recordings, and other information for Hackathons will be available on the GitLab Community Hackathon page.
The event planning will be done following the Hackathon issue template in the GitLab Hackathon project.
GitLab teams are encouraged to use the following Hackathon issue template to plan and prepare.
We also encourage wider community members to organize events to encourage and support new contributors to GitLab. This could be done as a part of in-person or virtual GitLab meetups.
If wider community members are interested in including a hackathon as a part of a meetup, ask them to include this information when they open a meetup issue. Contributor Success team members will get in touch with the organizer and provide the necessary resources to support the event.
Some of the available resources can be found in the hackathon-in-a-box folder, GDK tutorials playlist, etc. The program manager should also work with the organizer to create a list of issues that are good for first-time/inexperienced contributors and share the list with participants prior to the event. There should also be coordination with the organizer on GitLab merchandise that can be distributed to anyone who creates a Merge Request during the event.
To facilitate communication between the wider community and GitLab team members, product teams may host community office hours. The purpose of these office hours is to gather wider community feedback on product/development, discuss wider community contributions, review MR backlog, and other topics. Office hour related issues or MRs will have the label Office Hours as you can see in these examples.
Calls will be open to everyone and recordings will be posted after the call. See examples of past office hours from this playlist. To make it easier for the community to find the videos, each stage should create their own office hours playlist and link to it from their handbook page.
All the community office hour calls should be added to the Developer Evangelism calendar and meetup.com group.
Preparation
Running the call
After the call
To encourage contribution to priority issues on an on-going basis (and not just during Hackathons), we will maintain a list of up to 5 priority issues for each product stage and prizes will be given to wider community members who have MRs merged for these issues. These issues will have the label Community challenge and more details such as prizes, assignment of these issues, etc.
We run a Community Newsletter to share developer-focused content, alert community members about upcoming events, and keep contributors engaged. The focus of the newsletter is on driving contributions and engagement. It will not be used to generate or nurture leads and allow us to connect with and share our community's contributions.
To highlight issues that would be good for new contributors, you can add a label quick win. It is strongly recommended that these issues have mentor(s) listed so that the new contributor knows who they can get help from while they work on the issue.
The first-time contributors can be identified after each release in the First time contributors MRs dashboard.
Every time a contributor is opening a merge request to a GitLab namespace for the first time, the label "~1st contribution" is automatically applied to the merge request.
Once the merge request is reviewed and merged, the contributor can apply for the #myfirstMRmerged gift via a self-nomination form on the nominations for GitLab swag page.
Contributor Success team members can use the outreach email/message template when sending the link for the first-time contributor gift.
More information on the Core Team is available in the Core Team handbook page.
For contributors who don't own a credit card and need to be manually verified, a GitLab team member can open an internal request using the Other -> Other (nothing else fits the request) template. GitLab Support will follow the Manual credit card validation process described in the handbook to complete the request.
Wider community members may run out of monthly compute units, or run into other GitLab CI/CD limits if they are working from a personal fork.
The solution is to work from the GitLab community forks.
To be respectful to the contributor's privacy, we will only contact data that is publicly available to reach out to them.
Here are some ways to reach out to contributors to e.g. distribute Hackathon prizes or MVP swag:
If you need assistance finding a contributor's email address please see Finding Community Member Contact Information
Once you've found out the best way to contact them, you can choose to use a mention, e-mail or Twitter for instance.
Goal is to publish a regular blog post featuring contributors from the community. The format will be a casual Q&A with a community member and will be posted on the GitLab blog page.
When developing a blog post, follow the blog guidelines.
From time to time, a wider community member will submit a particularly outstanding contribution. Other than thanking them on the MR, we might want to additionally show our appreciation by sending them some GitLab merchandise. Anyone in the GitLab team or in the wider community can follow the process to nominate a contributor.
In order to recognize regular contributors, the list of top contributors for each calendar year will be published in the Top Annual Contributors page. There will be three categories of top contributors:
Customized GitLab merchandise will be created for these contributors and will be available on Printfection. For GitLab team members, you can follow the steps below to get the awards to the wider community members.
Campaigns, go to Giveaways and create a new GIVEAWAY CAMPAIGN (you may need to create a new Kit under the Merchandise tab if you want to include more than one item).In an effort to understand, support, and empower the GitLab code contributor community, we have come up with the following lifecycle segments:
| Contributor Experience level | MRs merged |
|---|---|
| New | 1-3 MRs |
| Experienced | 4-10 MRs |
| Advanced | 10+ MRs |
| Contributor Status | MRs merged | Timeframe |
|---|---|---|
| First time contributor | First MR merged | Current month |
| Regular Contributor | 10+ MRs | Last 6 months |
| Leading organizations | 20+ MRs | last 3 completed months |
| Inactive contributors | 0 MRs | last 6 months |
Segmenting our contributor community will allow us to understand better how contributors "move" across this funnel and how we can better support them through their journey.
The goal is to increase code contributors across all segments (except the inactive ones), by identifying ways to support and reward our contributors.
Note: this is currently a working list of all locations where we can currently gather contributor metrics. It is not yet the final set of metrics we will be using to monitor the success of the contributor program with.
The Bitergia dashboard is public and anyone can use the dashboard to view/filter/export/analyze the data. A good place to start is the Merged Community MRs dashboard as it includes information that most people are looking for such as merged community MRs, number of contributors (e.g. yearly), top contributors, merged MRs per milestone, etc. You can filter the dashboard data per milestone and repository (e.g. CE vs. EE).
| Dashboard | Description |
|---|---|
| Contributors | Metrics associated to contributors (people) and organizations |
| Contributions | Metrics associated to contributions (submitted MRs). It contains our main KPI. |
| Hackathon | Metrics associated to the quarterly GitLab Hackathon. Change the time scale to zoom into a specific Hackathon |
| Contributions and contributors over time | Overview of contribution and contributor growth over release, month and year time periods |
There are a number of other custom dashboards also available and to see the full list, click on dashboard on the upper left (next to the Bitergia logo) and then select the dashboard link from the list. To learn more about using the Bitergia dashboard, you can view recordings of Bitergia training at the Bitergia training livestream channel. Specific Bitergia documentation is available on the Bitergia FAQ.
Identity management is available on Bitergia's HatStall. Amongst other capabilities, HatStall enables merging/unmerging identities from the same person (to avoid their contributions being counted multiple times) and enrollment/offboarding identities to organizations. Use the same login as the main Bitergia platform.
Some administrative features for Bitergia dashboards (e.g. getting a short URL, creating a new permanent dashboard) require a login, and the login information is available in the Team Vault on 1Password.
GitLab has a subscription with Bitergia for an annual membership renewed on the 1st of October each year. Bitergia is responsible for sending a Statement of Work (SOW) to be signed by GitLab, a month prior the expiration of the license. Contributor Success' Director should include the Bitergia subscription in the program's annual budget planning.
The Bitergia team can be reached out for support and feature requests via their regular customer contact process
Internally, GitLab uses SiSense for tracking down the performance of various KPIs. Below you can find a list of community-related dashboards, similar to Bitergia's ones. Both tools, SiSense and Bitergia, are in sync, and we use Bitergia as the primary metrics platform for community contributions.
| Dashboard | Description |
|---|---|
| Wider Community Dashboard | Metrics associated to contributors (people) and organizations |
| Community Contributions KPI | Metrics associated to Developer Relations KPIs (like unique contributors per month, etc) |
| Wider Community Contribution Dashboard | Metrics associated to community contributions, including time to triage, MRARR forecast for merging month, etc |
You can also directly query data from Merge Requests pages for projects (e.g. CE, EE, Omnibus, Shell, etc.) on gitlab.com and apply appropriate filters for milestone, labels, etc. Some of the examples are listed in the metrics table below.
In the past we often mentioned 2,000+ contributors in the GitLab community (GitLab team members + wider community) as you can see in this example. However, this only included contributors to CE and EE projects based on the old https://contributors.gitlab.com page.
If you include other GitLab projects, the total number of contributors is much larger.
These figures count contributors who have opened at least one merge request, regardless of whether the merge request has been merged, closed or is still open.
When people ask about the number of contributors at GitLab, it's best to clarify if they're asking about total code contributors or wider community code contributors. In most cases, people tend to be more interested in the wider community number.
It's also important to mention that there are other ways the community contributes to GitLab other than code, as listed in our Contribute to GitLab guide. Contributions like Translations, Evangelism, support on our Forum, and opened issues are not included in the metrics above.
We monitor and recognize contributions across a variety of projects on the gitlab-org group, not only the GitLab project.
As a general rule, a project will be set up for monitoring wider community contributions if it uses the gitlab-org group milestones and the Community contribution label.
See the exhaustive list of monitored gitlab-org group projects.
Are you interested in contributing to GitLab? Check out the available contribution opportunities here.