Community forks: A new, easier way to contribute to GitLab

Apr 4, 2023 · 4 min read
Lee Tickett GitLab profile

At GitLab, we believe everyone can contribute. In my role, as a member of GitLab's Contributor Success team, I'm focused on ensuring that contributing to GitLab is as easy and rewarding as possible. In this article, I will share a recent experiment in improving the GitLab contributor experience for community members: community forks. I'll explain what they are and, more importantly, the positive impact we've seen community forks have on contirbutions to GitLab.

What is a community fork?

GitLab team members and wider community members have different levels of access to canonical GitLab projects. GitLab team members can contribute directly to the GitLab codebase; wider community members need to work from forks in order to contribute. This leads to two very different experiences. If you'd previously tried to contribute to GitLab from a personal fork, you probably encountered one of the following frustrations:

To address issues like these in the past, we'd developed and introduced solutions like cost factors. Those worked to alleviate individual pain points, but our team wanted to test another idea, one we thought could address a number of these contribution hurdles at once.

Drawing inspiration from Moshe Weitzman and a similar solution from the Drupal project, we imagined establishing a "community fork" of GitLab. Instead of working on innumerable, individual, isolated forks of GitLab, wider community members could all contribute to a single, shared fork of GitLab available to everyone.

Building the first fork

I spun up an issue and started to bounce ideas around. We were sure to involve the GitLab security team and the wider community before starting an experiment. After some conversations, I took a bias for action and created the first community fork. I shared this with a few regular community contributors (thank you, Marco and Niklas for beta testing and now also maintaining the forks). After a few weeks, we didn't encounter any problems, so we started spinning up forks of more GitLab projects, and invited more community members to join us.

We believe community forks have the following effects (you'll note that these tie back to the contribution challenges outlined above):

What's next for community forks?

The experiment was considered a success based on the following:

Thus, we are moving from "experiment" to "production".

The community forks concept forms part of my team's Q1 (February - April) objectives and key results (OKRs). As such, we have started updating the documentation and contributor guides and looking at opportunities for automation and promotion (for example, via @gitlab-bot).

We're also looking for opportunities to handle forks differently in the product. For example, there are several areas (such as the WebIDE) that only check for personal forks and don't consider other types of fork. Some backend pre-requisite work has already started to facilitate this.

We have been working on automating and managing the community forks via Terraform. This will make the process quicker, easier, and less prone to human error.

The Contributor Success team is already dogfooding the community forks, and promoting internally, hoping that eventually all GitLab team members will use the community forks. We'd love other open source projects to experiment with the concept and it become a new "norm" in community-driven open source software development.

You can read more about the community forks in the meta project. There you'll also find instructions for requesting access to community forks. If you have additional questions, why not ask our community members over on Discord?

Edit this page View source