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.
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
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.
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 throughput 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 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.
After the first merged MR, wider community members can order a #myfirstMRmerged gift via a self-nomination form on the nominations for GitLab swag page. You can use the outreach email template when you send the link for the first-time contributor gift.
The first-time contributors can be identified after each release in the First time contributors MRs dashboard.
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.
Follow the steps outlined in the sections below to create and edit GitLab EE licenses for contribution purposes.
To set up a dev.gitlab.org account to access license.gitlab.com (this is a one-off process):
Sign in with GitLab option while you are still logged into dev.gitlab.orgSign in with GitLab option.To edit an existing license (e.g. to extend it):
Edit license section.Duplicate license optionCreate License button to submit them.To create a new license:
New license buttonName, Company, Email, Users count, Plan code, Starts at, Expires at fields. For Core Team members, use GitLab Core Team (Development) as the company name. For other GitLab EE contributors, use GitLab Contributor (Development) as the company name.Notes section. This could indicate the purpose of the license or whether it's an extension, for instance.Create License button to submit them.Wider community members may run out monthly CI minutes as they are working on an MR. Community members can send a request to reset their CI minutes to contributors@gitlab.com 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 name, username, and link to the MR that requires additional CI minutes will need to be provided in the issue.
Wider community members under the Free tier on GitLab.com may run into GitLab CI/CD limits for max jobs or max pipeline schedules. Community members can send a request to get a temporary Bronze license in order to continue their contributions to contributors@gitlab.com. After reviewing the request, a Community Relations team member will file a support issue for Plan Change Request. In the issue, information on GitLab username/name space (if it's a group), contact email, end date, link to MR(s) that require additional CI/CD resources, etc. should be included.
Contribution 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 Meeting deck with the newly downloaded image.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).
There are a number of other custom dashboards also available and to see the full list, click on dashboard on the upperleft (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 (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.
The Bitergia team can be reached out for support and feature requests via their regular customer contact process
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.
When people ask about the number of contributors at GitLab, it's best to clarify if they're asking about total contributors or wider community contributors. In most cases, people tend to be more interested in the wider community number.
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.
