📖 Developer Satisfaction 2025 Report

💯 Code review

tl;dr

Following the announcement that we will continue to support both Gerrit and GitLab, both Gerrit and GitLab satisfaction is up:
- Gitlab – 53% are satisfied with Wikimedia's Gitlab, up from 46% last year.
- Gerrit – 75% are satisfied with Wikimedia's Gerrit, up from 64% last year.
Code review process – Like last year, folks say feedback is more helpful than timely.
- Gerrit stats for 2024:
  - Median time to merge: 0.58 days.
  - 75% of changes merge in less than 5 days.
  - 5% of changes take > 83 days to merge.
- Studies predicting code review sentiment conclude that long delays can make developers 45× more likely to be frustrated with the process.
- While our code review times compare favorably to other open source projects, our long tail of reviews means there are frustrated developers.

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

Of the 153 respondents who opted into this section, 84% 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 28 non-staff who responded to this question, similar to last year, the majority (71%), said that less than 10 percent of their time doing volunteer Wikimedia development work was spent reviewing others’ code.

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 (57%) of respondents reported spending more than 10% 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 (75%) of respondents indicated that feedback is always or often helpful
More than half (55%) 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

Finding reviewers

11 out of 42 answers (26%) mentioned difficulties with finding reviewers for code review.

Hard to find people who would review and merge patches even for MediaWiki core, never mind extensions..

[...] I wish code ownership was somehow integrated in the merge request workflow so that it would be easy to notify a suitable reviewer.

Visibility

Multiple commenters provided negative feedback related to visibility.

I feel like it takes forever to get anyone's attention. Listing a willing developer is also a nuisance - how am I able to figure out who's willing to review, can't read their mind.

Positive experience'

Multiple commenters provided positive feedback about the code review experience.

Review has become a lot simpler as the quality of the code has improved. from phcs to unit tests, namespacization, services, config system and the new db classes. It's just easier to comprehend.

I really like the community that takes part in (code) review processes. It's supportive, offers positive reinforcement and help instead of criticism and opinionated aggression (which I've sadly experienced in the past) and is a joy to be a part of. It makes the practice of reviewing code meaningful and rewarding! <3

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
25% said they were dissatisfied
1% 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 (compared to 64% last year)
10% said they were neither satisfied nor dissatisfied (compared to 11% last year)
15% said they were dissatisfied with Gerrit (compared to 25% last year)

top

# Gerrit activity

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

Of the 112 who responded, the majority said they had made more than 10 commits in the past year. Over one-third (40%) said they had made more than 100 commits in Gerrit last year, and over one-third (39%) said they had made 11-10. Less than a quarter (18%) said they had made 1-10.

We looked at (self-reported) Gerrit activity level by tenure. (Self-reported) commit activity was slightly higher for respondents with longer tenure.

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. 53% of respondents with 100+ Gerrit commits last year were very satisfied with Gerrit, compared to just 5% of respondents with 1-10 Gerrit commits.

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 2024, 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.

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.

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.

However, 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), overall Gerrit satisfaction decreases from 75% to 62% satisfied; and overall Gerrit dissatisfaction increases from 15% to 23% 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 bad

GitLab is just worse GitHub and the company behind it doesn't seem trustworthy. Gerrit is great.

Gerrit is bad

Gerrit is the absolute wors[t] thing within the Wikimedia/MediaWiki community and is the single thing stopping me from being more active within the community and submitting patches/contributions. [...]