Text of Sumana's talk at Wikimania 2011, "How to get what you want from the MediaWiki developers"

Session starting at 12:05

We have 20 minutes

Sumana Harihareswara, Volunteer development coordinator

used to measuring her effectiveness in laughs per minute
  • success & failures
  • processes

MediaWiki developed by a lot of people; volunteers & paid


1. Tiny, tiny paid staff. Top 10 website, with ~1% of the staff of the other major websites hiring people to work on mobile, i18n

But there are also things to be done to keep things moving. E.g. on testing

Our main aim = providing the service, not necessarily providing the software

We have a gazillion different interests from all our Wikimedia communities

2. Most of the paid staff is in SF, so they talk face to face.

This is part of why Sumana, Guillaume & Mark Hershberger exist. We are the canaries in the coal mine.

Communication channels[edit]

Where do devs look what communities want? Not at individual village pumps of 700+ wikis they look at bugs in bugzilla ( ), the wikitech-l mailing list (mail:wikitech-l ), Request for Comments on, the Tech blog ( ), project pages (that can be found in the monthly engineering reports like Wikimedia engineering report/2011/June ), IRC channels (#mediawiki, etc.)


How do we prioritize?

Community represented by the board. And also Strategic product team at the WMF Strategic product whitepaper,strategy:Product Whitepaper Bugs: Mark Hershberger trying to manage bugzilla


We rely on volunteers a lot for testing

Brion: we do look after things we know are likely to change and we try to reach out to people to fix it before it breaks, if possible. e.g. outreach to JavaScript devs when ResourceLoader was deployed.

Upgrades, shell requests[edit]

Local discussions do get viewed in this case, to assess community consensus (e.g. talk page, RfC, village pump, etc.)

Mark Hershberger also working on this


Siebrand Mazeland & Niklas Laxstrom from


A lot of the documentation about How mediawiki works is on

Mostly written by volunteers, as far as Sumana can tell.

How we failed and succeeded in the past[edit]

1. Really old bug #189 about sheet musics on Wikipedia, more than 100 comments, people frustrated that this has never been fixed at the beginning, not enough people to look at it & work on it it was also unclear back then about how things were prioritized

2. Pending changes Lots of people couldn't get a consensus in the community of en.wikipedia, but the WMF was also unable to support the community in structuring the discussion right (Sumana, please check this is what you meant) Yes, this is what I meant but I may be wrong :-)

3. Upload wizard and licensing tutorial If you ask for feedback during the whole process, it really helps, instead of doing something and communicating about it afterwards And all the team needs to be involved in the process, not just one person, who might become a bottleneck

4. Installer WMF staff completely rewrote the MediaWiki installer, even though the WMF doesn't directly benefit from it because they don't use it. But it was important to the dev community

Learn more[edit]

MediaWiki roadmap And other communication channels listed above

Make bigger impact on MW dev[edit]

1. file bug reports 2. Document & plan 3. talk to us at conferences 4. Evangelize, tell the world 5. If you're a technical person, try downloading & testing 6. Do bug triage

notes by Guillaume Paumier