Start contributing to GitLab today

At GitLab, everyone can contribute. This has been our mission from day one, since GitLab started as --and is still-- an open-source project.

We believe that, when consumers become contributors, it benefits everyone: GitLab the product, GitLab the company, GitLab the community as well as all GitLab users all around the world.

We already merged more than 7,700 “community contribution” merge requests from our wider community (at the gitlab-org group level).

Merge requests from community members not employed by GitLab (aka from the GitLab wider community)

Contributing tracks

Now, it's your turn to contribute and improve GitLab! Since not everyone share the same interests nor competencies, we have multiple tracks to ensure everyone can contribute:

• Development (new features, bug fixes, performance improvements)
• Documentation addition, improvements, and fixes
• Translations
• UX design
• Project templates

When you're ready, simply choose the track for you and follow the instructions.

Start small...

To get familiar with the merge request workflow, I advise you start small. Fixing a typo or adding a comma in the documentation are small yet awesome contributions that are usually merged in a matter of hours. These are awesome to gear up and get the ball rolling.

For more examples, be sure to take a look at the community merge requests that touched GitLab documentation.

These kind of changes don't require a lot of time from you, but if you have more time and are ready to tackle bigger challenges, you can start looking for bugs or feature proposals.

...and end up MVP

Every contribution is a collaborative effort between the merge request author, the reviewer(s), potentially MR coaches, and the maintainer (who gets to merge the MR).

Some contributions are so complex and technical that they take months of collaboration to get accross the finish line!

Let's give you a few examples of great collaborative efforts that happened in the last 12 months:

1. Cédric Tabin worked for more than 9 months contributing a new CI job keyword allowing interruptible builds and working with the GitLab teams to get it across the line. The merge request involved 51 people, who posted 405 discussion notes! This contribution was released in GitLab 12.3, and allows to save a lot of money by avoiding running redundant pipelines.
2. Tuomo Ala-Vannesluoma worked for 7 months adding support for previewing artifacts that are not public, a highly requested feature with almost 300 upvotes! The merge request landed in GitLab 12.4, and received two 🍾 emoji votes.
3. Roger Meier worked for more than 4 months contributing support for S/MIME Signature Verification of Commits, an important feature for sensitive projects and in regulated industries. Roger's teammate, Henning Schild, contributed the change upstream to Git and Roger made the change in GitLab. The merge request involved 42 people, who posted 430 discussion notes, and landed in GitLab 12.8.
4. Steve Exley worked for more than 5 months contributing one of the biggest architectural changes to the Docker executor. that solved multiple issues for the Docker executor, including jobs sharing the same network bridge, services don't work when network_mode is specified, and lastly, services can connect to one another and connect with the build container as well! The merge request involved 69 people, who posted 293 discussion notes. It landed in GitLab 12.9, and received five 🔥 emoji votes.
5. Jesse Hall worked for more than 5 months contributing one of the Batch Suggestions feature which allows MR reviewers to group all suggestions made to a diff and submit them at once. Because each suggestion translates into a Git operation, submitting these individually could take a long time if there were a large number of suggestions. Submitting suggestions in batches has numerous advantages, including time savings, efficient CI resource utilization (only one pipeline for all suggestions), and preventing an overly noisy Git history. The merge request involved 38 people, who posted 358 discussion notes. It landed in GitLab 13.2, and received seven 💚 emoji votes.

Get some help from the GitLab team

If you need any help while contributing to GitLab, below are some of the resources that are available.

1. Ask questions on the Contributors Gitter Channel.
2. Get in touch with Merge Request Coaches. To find a merge request coach, go to the GitLab Team Page and search for "Merge Request Coach". You can also mention Merge Request Coaches by typing @gitlab-org/coaches in a comment.
3. Find reviewers & maintainers of Gitlab projects in our handbook and mention them in a comment.
4. If you have feature ideas/questions, you can search for existing issues or create a new issue if there isn't one already. Feel free to mention product team members in the issue.

Wait for a reviewer. You’ll likely need to change some things once the reviewer has completed a code review for your merge request. You may also need multiple reviews depending on the size of the change. If you don't hear from anyone in a timely manner, feel free to find reviewers or reach out to Merge Request Coaches. Please don't be shy about mentioning GitLab team members in your merge requests as all team members are expected to be responsive to fellow community members.

How we stay on top of community contributions

In Q3 of 2020, several GitLab teams are focusing on improving the experience for community contributors. To achieve this goal, we created a few metrics around community contributions:

• Community Contribution Mean Time to Merge
• Unique Community Contributors per Month
• Community MR Coaches per Month

To make sure the GitLab team is working hand in hand with the wider community in a timely fashion, we've already put a few automations in place:

1. Every hour, wider community contributions are automatically labelled "Community contribution".
2. Every day, a report with the untriaged community merge requests is created and assigned to the Merge Request Coaches for triage. This ensures each merge request has a stage and group labels set.
3. Every two weeks, a report with unassigned and idle community contributions is created for each group.

These automations are powered by our triage-ops project and are documented in Triage Operations.

I hope this post convinced you to start contributing to GitLab. Keep in mind, any contribution is valuable, and don't worry, we're here to support you.

Cover image: "Żuki leśne na liściu jesienią" by Krzysztof Niewolny.