Are you interested in contributing to GitLab? Check out the available contribution opportunities here.
From the beginning, GitLab has been an open source project and we want to continue growing community code contribution. This will be accomplished by lowering the barrier to entry for new contributors and also by helping casual contributors become regular contributors. We want GitLab to be the open source project of choice for open source developers.
The current Code Contributor Program manager is Christos Bacharakis and you can find his contact information on his profile.
Alternatively, you can reach out to contributors AT gitlab DOT com via e-mail.
Like most open source projects, the GitLab Community also has a code of conduct to foster an open and welcoming environment. Instances of abusive, harassive, or otherwise unacceptable behavior may be reported to conduct@gitlab.com.
In case of a code of conduct violation, the following steps will be taken:
@abuse-team in the #abuse Slack channel to block the individual from GitLab.com.In general, it is best not to argue with someone who is not being constructive/respectful, and one should just focus on facts if you need to respond. If you need help with your response (including reviewing a draft of your response), you can ask in the #community-relations channel in Slack or email conduct@gitlab.com.
A GitLab contributor room is available on Gitter 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.
There is also a Sameroom tunnel between the Gitter contributor room and the #gitter-contributors-room Slack channel, so that GitLab team members can follow Gitter conversations and post to Gitter without leaving Slack.
You can use either channel to reply, as they are bidirectional. However, bear in mind of the limitations when replying from Slack
@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 contributors channel. Agenda, logistics, materials, recordings, and other information for Hackathons will be available on the Hackathon project pages.
The event planning will be done following the Hackathon issue template in the GitLab Hackathon project.
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. The code contributor program manager 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.
There is a public Community Office Hours calendar that you can use to schedule your team's events.
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.
To highlight issues that would be good for new contributors, you can add a label good for new contributors. 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.
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.
Submissions to the newsletter are always welcome. To share a contribution or a project you're working on with GitLab, find an active Newsletter Issue with the label Community Newsletter::Draft and add your content to the description.
Community Newsletter::Ready label and move content to Mailjet.Community Newsletter::Feedback and add a week to the due date to collect any feedback on the issue.Triage process for the new merge requests from the wider community opened on GitLab.com projects is outlined on Community Merge Request Triage Policies page.
Every hour the GitLab Bot automatically adds contribution labels to merge requests submitted by wider community members.
If you subscribe to any of those labels, you will also receive an email notification from the GitLab Bot. It's helpful to review these MRs to do some quick triaging to manually apply appropriate labels (e.g. corresponding devops/group stages) and mention GitLab team-members (e.g. product managers, engineering managers, technical writers for documentation, etc. ) so that the community MRs can be reviewed in a timely manner. You can refer to the product team handbook for the list of people you can mention in merge requests for each product area.
~"Community contribution": the main label to monitor for the Contributor Program. Also one of the type labels. Automatically applied by the GitLab Bot to MRs submitted by wider community members. It is added to GitLab projects and to the GitLab website (including the handbook). If you work with contributors, it is recommended that you subscribe to this label to receive e-mail notifications and thus be able to respond to those MRs in a timely manner. Remember to thank individuals for their contributions. Learn more about the cadence and conditions for this automation.1st contribution: this label is used to identify, thank and reward first-time contributors. It is automatically applied to the first MR each wider community member submits to a particular project. It is added to GitLab projects and to the GitLab website (including the handbook). First-time contributors are also awarded a gift as our way to say thanks and as a recognition for their work.Merge Request Coaches are available to help contributors with their MRs. This includes identifying reviewers for the MR, answering questions from contributors, educating contributors on the contribution acceptance criteria, or even completing the MR if the contributor is unresponsive or unable to complete it by adding the coach will finish label and creating a follow-up MR. Contributors can mention the coaches in their MRs by typing @gitlab-org/coaches.
Merge Request Coaches can be found using the list of current Merge Request Coaches, or on 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.
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. The following team members are members of the cla_managers@gitlab.com Google Group referred to on that page: Christina Hupy (Interim), Greg Myers, Dan Rhodes, and Christos Bacharakis.
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.
The Code Contributor Program manager 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 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. If they cannot complete their work in 30 days, a new EE license for 3 months for a limited number of users can be issued. If they want to continue contributing to EE beyond the 3 months (and there have been contributions during the 3-month period), we can renew the license for another 3 months by opening an issue using the Wider Community Contributor License Request.
Wider community members may run out of monthly CI minutes as they are working on an MR. Community members can send a request to reset their CI minutes by opening an issue at the Code Contributor GitLab repo in order to continue their work. After reviewing the request, a Community Relations team member will file an issue with the GitLab.com Support Team using the pipeline_reset_request template. Information on the community member's name, username, and link to the MR that requires additional CI minutes will need to be provided in the issue.
A GitLab team member can request to manually validate a contributor that doesn't own a Credit Card by opening a Support Internal Request.
I would like to manually verify the following GitLab contributor for allowing them to continue contributing: GITLAB_PROFILE_URL Thank youContribution to the GitLab Enterprise Edition requires accepting a Contributor License Agreement(CLA). In order to make the process as developer-friendly as possible, we do not require any paperwork and consider the act of submitting code via Merge Request as an agreement to individual or corporate CLAs.
The CLA only applies to GitLab EE, while other GitLab projects will continue to be licensed under MIT and simply require signing off on the Developer Certificate of Origin (DCO).
Code contribution to GitLab projects with the exception of GitLab Enterprise Edition (EE) requires signing off on the Developer Certificate of Origin (DCO).
In line with our value that everyone can contribute to GitLab, we strive to make our process as developer-friendly and frictionless as possible. As such, we consider the act of contributing to the code by submitting a Merge Request as the "Sign off" or agreement to the certifications and terms of the DCO and MIT license. No further action is required.
Check out this issue for more details.
Like most open source projects, the GitLab Community also has a code of conduct to foster an open and welcoming environment. Instances of abusive, harassive, or otherwise unacceptable behavior may be reported to conduct@gitlab.com.
In case of a code of conduct violation, the following steps will be taken:
@abuse-team in the #abuse Slack channel to block the individual from GitLab.com.In general, it is best not to argue with someone who is not being constructive/respectful, and one should just focus on facts if you need to respond. If you need help with your response (including reviewing a draft of your response), you can ask in the #community-relations channel in Slack or email conduct@gitlab.com.
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:
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.
A weekly issue (an example) highlighting wider community MRs that require attention will be sent to MR coaches. Follow-ups should be made on inactive MRs with either wider community members or reviewers to ask if there's a plan to continue the work or if MR should be closed.
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.
Every release, a contributor is selected as a Most Valuable Person (MVP) for significant contribution(s) for that release. Suggestions/discussions for the MVP take place in the #release-post Slack channel. GitLab team-members and Core Team members are all encouraged to participate in the MVP discussion. Based on the discussion in the Slack channel, the release post author for each release will make a decision on the MVP.
Some common criteria to weigh who to nominate and who should be selected:
See the Release Posts section for more details on how to add an MVP to the release post.
After each release, MVPs are added to the GitLab Hall of Fame.
Every release GitLab chooses a Most Valuable Person (MVP) and recognizes them for their contributions. The Advocates team then privately sends them some GitLab swag as a thank you.
Our Code Contributors program manager will choose the MVP of the release. Before release day, the release day manager will tag advocates in the #swag Slack channel, or in the Release Day issue, as a reminder to send swag to the chosen MVP.
#release-post channel+ Get New Link buttonMark Link as Sent once it's sentCongratulations on being the MVP for GitLab's (enter release number here. ex. 13.3) release! 🤸♂️
https://about.gitlab.com/community/mvp/
We are so amazed by your work and we want to thank you for your contributions: please enjoy some well deserved GitLab swag! We can't wait to see what you do next!
Link to collect swag:
(paste Printfection link here, and opt to add the printfection code as well)
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).Download Image.Contributions chart in the Marketing Key Review deck with the newly downloaded image.In an effort of understanding, supporting and empowering the GitLab code contributor community, we have come up with the following lifecycle segments:
| Name | Description | Requirements |
|---|---|---|
| New Code Contributors | People who have contributed to GitLab at least once. | 1 MR merged |
| Active Code Contributors | GitLab's currently active code contributors. | 1+ merged MR during the last 6 months |
| High Performing Code Contributors | People with a significant number of MRs. | 10+ merged MRs in one milestone OR 1+ merged MRs across 3 milestones |
| Inactive Code Contributors | People who haven't been contributing for the past 6 months | Not a merged MR for 6+ months |
| Reactivated Code Contributors | People who became inactive and then active again | 1+ merged MR during the last 6 months after not having an MR merged for more than 6 months |
Segmenting our code 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. The Code Contributor Program Manager 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 Community 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, Gitter, 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, Engagement, 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.
Over the years, the code contributor program has been closely collaborating with various GitLab teams to increase contributions while streamlining the contribution process.
Community Relations team and the Quality department is currently collaborating on Contribution Efficiency, where the group's primary focus is to identify opportunities for improving the contributor experience (quicker review time, automation, etc) and internal processes.