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 community room is available on Gitter for people interested in contributing to GitLab. This is open to everyone to join.
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.
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 Contribute for prize and more details such as prizes, assignment of these issues, etc. can be found here.
To highlight issues that would be good for first time contributors, you can add a label Good for 1st time contributors. These issues must have mentor(s) listed in the issue so that the new contributor knows who they can get help from while they work on the issue (see this example from the Runner project). If you are not able to commit to mentoring a new contributor, you should not use the Good for 1st time contributors label.
The GitLab Bot automatically adds contribution labels to merge requests submitted by wider community members, once a day (Monday-Friday).
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 stage) 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.1st contribution: this label is used to identify, thank and reward first-time contributors. It is manually 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. Note: there are multiple open issues related to automating the addition of this label.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, reach out to new contributors using the outreach email template to congratulate them on the first MR and offer a GitLab merchandise. In cases where it would be beneficial for new contributors to be paired up with an experienced mentor, you can make an offer for a mentor for a limited time period (~2 weeks) so that mentors are not overly burdened. Currently, mentors consist primarily of Core Team members.
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.
In order 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 the contributor is not able to complete their work in 30 days, issue a new EE license for a 3-month period for a limited number of users. If the contributor wants to continue contributing to EE beyond the 3 months (and there has been contributions during the 3-month period), we can renew the license for another 3-month period.
In order to request license keys for EE, you will need to get permission to login to dev.gitlab.org by creating an access request issue. Details on requesting license keys can be found at Working on GitLab EE section of the developer onboarding handbook.
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.
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.
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.
Periodically, there should be a review of community MR's that has not had a meaningful activity for an extended period (e.g. >3 months). A good place to start would be to search for all MR's with a label Community contribution and a milestone No milestone. A follow-up should be made with either the community member or MR coaches to ask if there's a plan to continue work on the MR or if MR should be closed.
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.
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.
Number of merge requests (MRs) merged from the wider GitLab community for each milestone.
To count as a contribution:
Community contribution label11.11, 12.0, etc.)gitlab-org group projectsNotes:
Community contribution label was created.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.
Some administrative features (e.g. getting a short URL, creating a new dashboard) require a login, and the login information is available in the Team Vault on 1Password.
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 more than 4,500.
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.
The list of GitLab projects that we track contributions for is maintained in Bitergia's GitLab projects file.
