📖 Developer Satisfaction 2026 Report

💯 Code review

tl;dr

Gerrit and GitLab both had the same satisfaction numbers as last year:
- GitLab – 53% are satisfied with Wikimedia's GitLab, Same as last year.
- Gerrit – 75% are satisfied with Wikimedia's Gerrit, Same as last year.
Code review process – Like last year, folks say feedback is more helpful than timely.
- Getting code review was mentioned as one of the biggest pain points overall for developers, especially volunteers.
- Gerrit stats for 2025:
  - Median time to merge: 0.58 days.
  - 75% of changes merge in less than 5 days.
  - 5% of changes take > 87 days to merge. (up, slightly, from 2024)

In the past year, have you had your code reviewed by someone else or reviewed someone else's code

Of the 125 respondents who opted into this section, 76% either reviewed code, had their code reviewed, or both.

# Time spent on code review per week

Volunteers
“In the past year, on average, what percentage of your time doing volunteer Wikimedia development work was spent reviewing others’ code?”
last year

Of the 27 non-staff who responded to this question, similar to last year, the majority (59%), said that less than 10 percent of their time doing volunteer Wikimedia development work was spent reviewing others’ code. Last year, 71% of non-staff volunteers said less than 10 percent of their time.

WMF/Affiliate staff
“In the past year, on average, about how many hours per week did you spend reviewing others’ code as part of your role as a member of the Wikimedia developer community?"
last year

The hours were then converted into a weekly percentage based on an assumption of a ~40 hour work week.

Similar to last year, the majority (51%) of respondents reported spending more than 10 percent of their working hours reviewing others’ code.

top

# Code review quality

During the past year, how often is code review feedback helpful? How often is it provided in a reasonable amount of time
last year

A majority (87%) of respondents indicated that feedback is always or often helpful
More than half (54%) said that feedback is always or often timely

top

# Feedback on the code review process

“Please share any other feedback you may have about the code review process”
last year

Getting code review is hard

40% of all comments were about difficulties getting code review.

It's still and always has been one of the number 1 problems at Wikimedia. It needs to be taken more seriously. I am meanwhile convinced that only a top-down approach will help. Directors need to tell engineers that ignoring code review requests and filtering gerrit/gitlab emails is NOT OK.

27% of comments were specifically about how hard it is for volunteers to get code review.

A single small/medium tweak a beginner learner and first-time contributor may do also takes at least 2 months to get reviewed and merged. While I understand many are volunteers and code review takes time, this is a very long period of time during which a potential newbie might be discouraged to continue and eventually give up contributing.

top

# Gitlab satisfaction

“Thinking of your experience in the past year, how satisfied are you with Wikimedia’s Gitlab?”
last year

53% said they were satisfied with Wikimedia’s Gitlab
21% said they were neither satisfied nor dissatisfied
22% said they were dissatisfied
4% were unsure

top

# Gerrit satisfaction

“Thinking of your experience in the past year, how satisfied are you with Wikimedia’s Gerrit?”
last year

75% said they were satisfied with Gerrit
12% said they were neither satisfied nor dissatisfied
12% said they were dissatisfied with Gerrit
1% said they were unsure

We also looked at Gerrit satisfaction by tenure.

top

# Gerrit activity

“In the past year, about how many commits have you made in Gerrit?”
last year

Of the 85 who responded, the majority said they had made more than 10 commits in the past year. More than one-third (36%) said they had made more than 100 commits in Gerrit last year, and more than one-third (38%) said they had made 11-100. Less than a quarter (21%) said they had made 1-10.

top

# Gerrit satisfaction (by Gerrit activity level)

We looked at Gerrit satisfaction by respondents’ Gerrit activity level (i.e., by respondents’ self-reported number of commits made in Gerrit last year).

Respondents with higher levels of activity in Gerrit were more satisfied with Gerrit. More than half (58%) of respondents with 100+ Gerrit commits in the past year were very satisfied with Gerrit.

Additional year-over-year trends worth noting:

This year, 38% of respondents with 11-100 Gerrit commits were very satisfied with Gerrit, compared to 23% last year.
This year, 28% of respondents with 1-10 Gerrit commits, compared to just 5% last year.

Weighting by Gerrit activity

Like last year, folks who took this survey are more active users of Gerrit than most.

We know this because we know how many commits every user of Gerrit in 2025, and we can compare that to the self-reported Gerrit activity from this survey. When we do that, we find folks who took this survey are more active than most Gerrit users.

Two possible causes:

Gerrit/Survey popularity — More-active Gerrit users take this survey. Maybe because they saw it advertised on Gerrit (likely).
Estimation – Survey respondents systematically overstated their Gerrit activity.

Using their self-reported Gerrit commits, we can weight answers to better-represent the population of Gerrit users (by Gerrit activity). So, responses from folks with a lot of Gerrit commits end up counting a little less, and responses from folks with fewer Gerrit commits end up counting a bit more. We think these weighted estimates are useful context for understanding how responses might change if we were able to survey every Gerrit user.

Weighted satisfaction

When we apply the weighting (i.e. when we downweight the responses of highly active Gerrit users, and upweight the responses of less active Gerrit users), Gerrit satisfaction changes only slightly. The percentage of "very satisfied" drops from from 40% to 36%; and the percentage of "very dissatisfied" increases from from 6% to 7% dissatisfied.

top

# Feedback on code review tools

“Please share any other feedback you may have about code review tools”
last year

Like last year, many respondents told us why Gitlab is bad and Gerrit is good, while many others told us why Gerrit is bad and Gitlab is good.

Gitlab is mentioned in 12 comments.

We tagged 2/12 comments mentioning GitLab as positive.

Using more modern tools like GitLab or GitHub would significantly lower the entry barrier for most new developers

We tagged 9/12 comments mentioning GitLab as negative.

Code review on gitlab is mid when compared with gerrit.

Gerrit is mentioned in 14 comments.

We tagged 3/14 comments mentioning Gerrit as negative:

The WMF should not be using Gerrit in 2025 if they expect to recruit and retain volunteer developers.

We tagged 10/14 comments mentioning Gerrit as positive:

I have zero need for GitLab and the introduction of it made my life harder instead of easier. It also makes the review problem described earlier even worse because you can't add more than one reviewer at a time. I am glad that we got to keep Gerrit.

Gerrit is really powerful and useful, I love it so much! Thanks for keeping it running! :)

Whenever I have to use a repo which is on Gitlab, it's a pain. It's so limited that I'm 10% as productive as when using Gerrit.