The Wikimedia Foundation has found that the results of a developer satisfaction survey conducted over the past two years have raised complaints about the code review system Gerrit.
In particular, Gerrit’s interface has a reputation for being difficult to use. The workflow is different from the industry’s mainstream method, so many developers disliked it. The Wikimedia Foundation also said that it took time for new tech staff to get used to Gerrit, raising the bar for new entrants to the Wikimedia community.
Official position announced by Wikimedia
For the past two years, our developer satisfaction survey has shown that there is some level of dissatisfaction with Gerrit, our code review system. This dissatisfaction is particularly evident for our volunteer communities. The evident dissatisfaction with code review, coupled with an internal review of our CI tooling and practice makes this an opportune moment to revisit our code review choices.
While Gerrit’s workflow is in many respects best-in-class, its interface suffers from usability deficits, and its workflow differs from mainstream industry practices. This creates barriers to entry for the community and slows onboarding for WMF technical staff. In addition, there are a growing number of individuals and teams (both staff and non-staff) who are opting to forgo the use of Gerrit and instead use a third-party hosted option such as GitHub. Reasons vary for the choice to use third-party hosting but, based on informal communication, there are 3 main groupings:
- lower friction to create new repositories
- easier setup and self-service of Continuous Integration configuration
- more familiarity with pull-request style workflows
All these explanations point to friction in our existing code-review system slowing development rather than fostering it. The choice to use third-party code-hosting hurts our collaboration (both internal and external), adds to the confusion of onboarding, and makes it more difficult to maintain code standards across repositories.
The Wikimedia Release Engineering team has taken an initial look at GitLab.
GitLab is a capable and scalable code review system written in Ruby. GitLab is available for self-hosting, as required for parity with the rest of our development tooling infrastructure and to alleviate concerns about data privacy or usage restrictions of third-party hosting. As GitLab offers an MIT licensed community edition (CE), it adheres to the Foundation’s guiding principle of Freedom and open source.
Finally, GitLab was evaluated as part of the Release Engineering team’s Continuous Integration working group. While GitLab’s continuous integration systems were found to be adequate for our needs, code review was out of scope for the charter of that working group. Therefore GitLab’s capabilities were weighed against the likelihood of introducing social friction and added complexity – integrating GitLab’s CI with Gerrit. Replacing Gerrit with GitLab would significantly change the equation of our CI tooling – allowing us to use an industry-standard workflow and self-serve CI tooling built into GitLab. For these reasons we’d like to limit the scope of this discussion to evaluation of whether it’s feasible and advisable to move from Gerrit to GitLab for code review.
