Developer Satisfaction Survey/2024/Overall

πŸ“–Β Developer Satisfaction 2024 Report

πŸŒ€ Overall edit

tl;dr

We asked survey takers, β€œOverall, thinking of your role as a member of the Wikimedia developer community in the past year, how productive do you feel?”

Three-quarters (75%) of respondents indicated that they felt very or moderately productive.

How productive do you feel?

Response Respondents Percent
Very productive 35 21%
Moderately productive 89 54%
Not very productive 25 15%
Not productive at all 7 4%
Unsure 10 6%
Grand Total 166 100%

top


# Satisfaction

We asked survey takers, β€œOverall, thinking of your role as a member of the Wikimedia Developer Community in the past year, how satisfied are you with the overall Software Development Life Cycle?”

Half (50%) of respondents were satisfied, while 22% were neutral, 18% were dissatisfied, and the remaining 10% were unsure.

top


# Perception of Wikimedia's developer community

We asked participants how much they agree or disagree with statements of the Wikimedia developer community as welcoming, diverse, dedicated, and collaborative.

More than half of respondents agreed that the community is dedicated (77%), collaborative (75%), and welcoming (63%). Almost half of respondents agreed that the community is diverse (48%), while 14% were neutral, 19% disagreed, and the remaining 19% were unsure.

top


# Most important

We asked survey takers, β€œIn your opinion, the most important thing we could do to improve the Wikimedia developer experience is…” Several themes emerged from the answers.

Decision making

Create a fair, transparent and equitable process for collective decision making around architecture.

Sunset products […] that don't have any active product management any more.

Bug triage/Code review process

Focus on code review culture and stewardship. Imagine a world where every patch gets some kind of feedback in less than 24hours without someone having to pester someone else.

Address old Phab-tasks and Gerrit-patches and find ways to lower review/pending times in general. Things should either be accepted or refused; They shouldn't be stalled into oblivion.

improve triage/ownership of bug reports in code that is deployed as part of Wikipedia.org, and at least acknowledge and maintain awareness of patches to those code bases that are deployed to Wikipedia.

Developer environments

Build, maintain and document better developer environments that are easy to set up

Improve code reviews and dev envs (fix beta)

It would be nice to have an easy way to replicate the production environment locally with the wikifamily and jobqueue setup.

Simplify setup and environment creation, including seed data.

Onboarding/streamlining

make it easier to get started: from getting credentials for gerrit/phab/cloud, to getting a dev environ set up, to help with a small first patch (incl timely code review) to getting work rolled out into production.

Onboarding documentation and tutorials.

streamline the contribution flow β€” from submitting code, to finding reviewers, to reading the docs, to communicating with the technical community. There are way too many papercuts across all these steps.

Write cohesive documentation for how to MAKE things, instead of sprinkling all the knowledge into 10000 wiki pages.