4 ms·

[Former product manager at the Wikimedia Foundation and longtime Wikipedia editor/admin here.] The author of the op-ed is a devoted editor but seems almost tot

[Former product manager at the Wikimedia Foundation and longtime Wikipedia editor/admin here.] The author of the op-ed is a devoted editor but seems almost totally ignorant of how development is conducted. The Foundation has been doing transparent quarterly/yearly roadmap planning alongside their annual plan / budget cycle (which is shared all publicly). On a shorter timeframe, they are pretty serious about Agile/Scrum. You can see on https://wikimediafoundation.org/wiki/Staff_and_contractors https://wikimediafoundation.org/wiki/Staff_and_contractors that today they even have a team of half a dozen full time Scrum masters. If what he thinks is missing is serious, detailed planning, he's sorely wrong. The platform (MediaWiki) is still a FOSS community so you can find project requirements docs/roadmaps all over mediawiki.org, all the bugs on Phabricator, follow along on mailing lists, and even see commits on their Gerrit instance. Agile isn't my cup of tea personally and I could grok criticisms of the organization's software output (ignoring the fact that they're buried under 10+ years of technical debt...), but it takes minimal digging to find all their plans and timelines. I would venture that the author chose not to dig into this because he, like a lot of entrenched old school editors, viscerally hates some of the past attempts to make MediaWiki a modern collaboration platform, such as building a WYSIWYG editor and a threaded discussion system to replace wiki talk pages.

saurik 9y ago
Where can one find out what percentage of Wikimedia's developer staff resources (as opposed to open source contributors) are being allocated towards what projects? They are spending $31m this year on staff: what percentage of that is being spent on what kinds of staff (ex. software engineer vs. community manager), and what percentage of their developer staff is being used to build these aforementioned projects? If that number is extremely low then you can just discount that issue, but if that number is enourmous then more questions have to be asked (which would of course involve looking at the success metrics on those projects and what validation was done on them while they were designed). As it stands, Wikimedia is constantly asking for more money using the threat that Wikipedia will collapse, when for all we know most of their staff time is off building stuff like Wiktionary.
- swalling 9y ago
  Their Annual Plan with spending breakdown is published every year on wikimediafoundation.org. The draft for the upcoming year is https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2017-2018/Draft/SinglePage https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_... TL;DR: the largest chunk of the budget goes to the two departments that do engineering/design/PM/data science. On your last point ("for all we know most of their staff time is off building stuff like Wiktionary") it's actually a big gripe in the smaller communities that probably 90% of the time and attention goes to Wikipedia.
  - saurik 9y ago
    Ok, so from this I see that $20m/year is going towards staff for "product" and "technology"; but there is no breakdown on what that is being spent towards. The point I was making is that if we knew the percentage of effort going towards engineering and multiplied it by the percentage of time being allocated towards some targeted projects and that value was low, then it would not be relevant... but we only have he first number and that number is high enough to mean we have to be concerned by the second number. Spending $20m for a year of engineering effort is a ridiculously large number for a website that fundamentally does as little as Wikipedia does... what was shown for it and what percentage of that can be allocated towards each outcome?
elect_engineer 9y ago
(I am the author of the op-ed. A better version is at [ https://en.wikipedia.org/wiki/User:Guy_Macon/Wikipedia_has_Cancer https://en.wikipedia.org/wiki/User:Guy_Macon/Wikipedia_has_C... ].) I am very familiar with Agile and Scum, and I have seen the advantages over older paradigms such as waterfall. That being said, there are certain basic principles that the old methods and the new methods have in common. One such principle is the basic idea of having some sort of contact with the people who will be using the finished software and understanding their needs. The WMF does not do that. Instead, they build something in secret, throw it over the wall, and watch as the Wikipedia editors reject it as the steaming pile of crap that it is. They have done this again and again. Visual Editor. Flow. Mobile App. Knowledge Engine. All failures. All built without any input from the people who would be using them. Now I KNOW that the developers are not stupid or ignorant, and I have checked as best I can and it appears that every one of them was able to create high quality software that meets the customer's needs when they were working other places. That leaves me with management as the probable culprit. And I don't think that the problem is product managers like the author of the post above this one. I think the blame is at the very top. I would advise anyone who really wishes to understand these issues to at least read the pages linked to on my [ https://en.wikipedia.org/wiki/User:Guy_Macon/Wikipedia_has_Cancer https://en.wikipedia.org/wiki/User:Guy_Macon/Wikipedia_has_C... ] page, especially [ http://mollywhite.net/wikimedia-timeline/ http://mollywhite.net/wikimedia-timeline/ ] Finally, if it really "it takes minimal digging to find all their plans and timelines", I would like to see this demonstrated by providing links to the plans and timelines for the Knowledge Engine. --~~~~

saurik 9y ago

Where can one find out what percentage of Wikimedia's developer staff resources (as opposed to open source contributors) are being allocated towards what projects? They are spending $31m this year on staff: what percentage of that is being spent on what kinds of staff (ex. software engineer vs. community manager), and what percentage of their developer staff is being used to build these aforementioned projects? If that number is extremely low then you can just discount that issue, but if that number is enourmous then more questions have to be asked (which would of course involve looking at the success metrics on those projects and what validation was done on them while they were designed). As it stands, Wikimedia is constantly asking for more money using the threat that Wikipedia will collapse, when for all we know most of their staff time is off building stuff like Wiktionary.

swalling 9y ago
Their Annual Plan with spending breakdown is published every year on wikimediafoundation.org. The draft for the upcoming year is https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2017-2018/Draft/SinglePage https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_... TL;DR: the largest chunk of the budget goes to the two departments that do engineering/design/PM/data science. On your last point ("for all we know most of their staff time is off building stuff like Wiktionary") it's actually a big gripe in the smaller communities that probably 90% of the time and attention goes to Wikipedia.
- saurik 9y ago
  Ok, so from this I see that $20m/year is going towards staff for "product" and "technology"; but there is no breakdown on what that is being spent towards. The point I was making is that if we knew the percentage of effort going towards engineering and multiplied it by the percentage of time being allocated towards some targeted projects and that value was low, then it would not be relevant... but we only have he first number and that number is high enough to mean we have to be concerned by the second number. Spending $20m for a year of engineering effort is a ridiculously large number for a website that fundamentally does as little as Wikipedia does... what was shown for it and what percentage of that can be allocated towards each outcome?

elect_engineer 9y ago

(I am the author of the op-ed. A better version is at [ https://en.wikipedia.org/wiki/User:Guy_Macon/Wikipedia_has_Cancer https://en.wikipedia.org/wiki/User:Guy_Macon/Wikipedia_has_C... ].) I am very familiar with Agile and Scum, and I have seen the advantages over older paradigms such as waterfall. That being said, there are certain basic principles that the old methods and the new methods have in common. One such principle is the basic idea of having some sort of contact with the people who will be using the finished software and understanding their needs. The WMF does not do that. Instead, they build something in secret, throw it over the wall, and watch as the Wikipedia editors reject it as the steaming pile of crap that it is. They have done this again and again. Visual Editor. Flow. Mobile App. Knowledge Engine. All failures. All built without any input from the people who would be using them. Now I KNOW that the developers are not stupid or ignorant, and I have checked as best I can and it appears that every one of them was able to create high quality software that meets the customer's needs when they were working other places. That leaves me with management as the probable culprit. And I don't think that the problem is product managers like the author of the post above this one. I think the blame is at the very top. I would advise anyone who really wishes to understand these issues to at least read the pages linked to on my [ https://en.wikipedia.org/wiki/User:Guy_Macon/Wikipedia_has_Cancer https://en.wikipedia.org/wiki/User:Guy_Macon/Wikipedia_has_C... ] page, especially [ http://mollywhite.net/wikimedia-timeline/ http://mollywhite.net/wikimedia-timeline/ ] Finally, if it really "it takes minimal digging to find all their plans and timelines", I would like to see this demonstrated by providing links to the plans and timelines for the Knowledge Engine. --~~~~