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:
- You need to fork the project before you can begin working on a code contribution. (This can take a while for big projects such as GitLab and www-gitlab-com.)
- Collaboration is "opt-in". That is, a contributor must manually opt-in to allow maintainers to push commits to their merge requests, and community members cannot push commits to team member branches.
- Free tier quotas apply to individual contributors' forks. This can create a challenge when frequent contributors use up their free CI minutes allocation.
- Personal forks need to be regularly updated (rebased) against the canonical projects.
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):
- Promote collaboration
- Community members and team members can work on the same merge request (pushing commits to eachother's branches).
- They can also take over stuck/idle merge requests (from each other and from team members).
- Remove blockers
- Personal CI minute and storage quotas do not apply to the community forks as they are part of the GitLab for Open Source Program which provides GitLab Ultimate tier benefits (including larger quotas).
- Improve efficiency
- There is no longer a need to create a personal fork to get started contributing.
- Danger runs automatically, without the need to configure personal access tokens and CI variables.
- Pull mirroring keeps the community forks up to date, without regular manual rebasing.
What's next for community forks?
The experiment was considered a success based on the following:
- The problems identified and effects predicted were confirmed.
- Adoption has been simple.
- Feedback has been positive (both from community members and GitLab team members).
- No blocking issues/concerns have been identified.
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?
