The Wikimedia Foundation sometimes proposes new features that receive substantive criticism from Wikimedians, yet those criticisms may be dismissed on the basis that people are resistant to change—there's an unjustified view that the wikis have been overrun by vested contributors who hate all change. That view misses a lot of key details and insight because there are good reasons that Wikimedians are suspicious of features development, given past and present development of bad software, growing ties with the problematic Wikia, and a growing belief that it is acceptable to experiment on users.
There's a lot of agreement about the major technical pain-points of Wikimedia wikis. Any non-programmer who has interacted with a MediaWiki talk page or tried to edit a marginally complex article can quickly identify problems with the MediaWiki software and its design. Talk pages are horrific. Editing is horrific. Page load time—particularly for logged-in users and particularly for articles with a high number of complex templates—can be horrific. Change is needed; or to put it even more politely, there's a lot of room for improvement.
Agreement aside, we're seeing a disconnect right now between what the Foundation is spending resources on and the issues faced by the community. This misalignment has a number of origins. While many people agree that change is needed, the question is whether the Foundation will deliver these changes.
Wikimedians are wary because the Foundation has been producing bad software. The bad software can be split into two groupings: older and more bloated, and the newer and less bloated.
FlaggedRevs is an example of the former. After years of delays, it was rebranded at the last minute as "Pending Changes", finally deployed to the English Wikipedia, and was a complete flop. The software was bloated, slow and inflexible, and was marred by poor usability. Ultimately, even its most die-hard fans saw that it was not going to work. Rather than focusing on improving the software, the Foundation dragged its feet and largely ran out the clock on the extension. The hope was presumably that eventually everyone would focus themselves on something other than the BLP problem, a strategy that was successful.
LiquidThreads is another example of older, bloated, bad software. Again, it was developed over years, was finally deployed to a number of smaller wikis, and was a disaster. It had substandard usability and very little support from the Foundation. Eventually it was abandoned, leaving small wikis (and anyone else who had the misfortune of having decided to use it) with absolutely no upgrade path.
More recently a newer type of bad software has been emerging, less bloated (in the sense of being meant for niche uses rather than general use) and more expensive. This includes MoodBar, ArticleFeedback (in its umpteen versions), and WikiLove. These software come with costs. The first and most prominent is that these features—as childish and valueless as they are—deplete a finite set of resources available for software development. In other words, these endeavors waste human resources. Established editors largely roll their eyes at the features and hope they don't make too much of a mess.
The secondary cost of requiring established users to administer these poorly thought-out and inadequately developed extensions cannot be overlooked. As surprising as it may be, given the years of development ploughed into them, a number of these extensions were deployed without anti-abuse mechanisms. This is unacceptable. Article feedback is a safe haven for spam and other useless noise. WikiLove is more often used by spammers and others who have no idea what it is or why it's there than it is used legitimately.
Some development of bad software is the natural result of the Foundation's growing pains. Not every line of code is going to be magical and work well, especially on first try. But it's unclear how much the Foundation has learned from its past mistakes. The lack of follow-through with its software development and the quick abandonment of any difficult project (FlaggedRevs, LiquidThreads, etc.) is troubling. The same people who worked on some of these past duds are now being brought in to lay the groundwork for other redesigned and re-engineered projects. We're seeing the same worrying trend of bringing in a contractor, who starts the development work, then leaves before it's finished. The code then rots.
The newer category of software is part of the Foundation's "Wikiafication" efforts. Most people know Wikia as that family of wikis overrun by advertising, full of low-quality content, and bloated by poorly optimized code, making the site slow and generally unappealing. This has become the Foundation's model to follow, and the long-standing closer relationship with Wikia makes many Wikimedians very cautious.
The for-profit nature of the site aside, Wikia has engaged in a number of poor social and technical practices over the years that have disrupted and harmed its communities. Wikia is a bad model, and the increasingly close collaboration between the Foundation and Wikia on projects and development is cause for concern. That said, learning from Wikia's mistakes in areas such as the development of a visual editor is not a bad idea. The Foundation should look at Wikia as a model of what not to do and figure out strategies to avoid following in its footsteps.
As though negative past experiences and a growing relationship with Wikia were not enough, Wikimedians have also become increasingly concerned at the emergence and growth of experimentation on the projects.
The proper role of experimentation is incredibly tricky to tease out. Some of the ethical questions are enhanced on Wikimedia projects because of the volunteer nature of most project participants and the complex relationship between the Foundation and the volunteer editing community.
The Foundation sees it as acceptable to experiment on users. In the Foundation's eyes, users are viewed and treated as customers, not colleagues. This is very dangerous and is a major contributing factor to the wariness (and weariness) with which Wikimedians view the Foundation. There is a cost to any of these experimental features on the editing community, and user experience is difficult to optimize under even the best circumstances. A keen understanding of user workflow is required to make non-disruptive, helpful changes. Many Foundation employees don't understand editor needs because they are not editors. In place of this understanding is the view, as expressed by one Foundation employee, that "we will allow ourselves to behave like elephants from time to time and we expect to be suffered."
Wikimedians are rightfully skeptical.
How do we move forward? The past and the present are interesting to focus on, but the future is of most concern.
The lines of communication between the editing community and the Foundation must be opened. It's not just about soliciting feedback; it's about engaging in useful conversation and adapting ideas accordingly.
With any big change, it helps to be up-front and to give a lot of warning about upcoming changes. People, particularly volunteers, do not like unexpected changes. The Vector roll-out was a slow process and that slow speed helped a lot. Posting mock-ups and design documents on MediaWiki.org (as all engineering projects are now expected to do and are actually doing) is a great step forward. Adding notes to the top of the page that make it seem like outside contribution is unwelcome is a small step backward. The Foundation should not be posting op-eds in which it lays out "changes you should expect to see". Rather, it should post design documents and other pages on mediawiki.org and in other public places that convey a different message: "These are our current thoughts; how can we make this better? What problems do you anticipate with these ideas? Can you suggest any alternatives?". This attitude of publishing edicts on design or features engenders yet more hostility and distrust of the Foundation.
For every change, there must be appropriate planning for Wikimedia's needs. This means asking the editing community what the pain-points are going to be and figuring out ways to solve these early on in the design phase. Building an entire tool without any anti-abuse features is no longer acceptable. Abuse is a known fact with any tool and must be taken into account; only "really wiki" features (based on wikitext in wiki pages rather than JavaScript and database injections) can rely on the normal self-healing features of wikis. For some (though not all) features, an opt-out option must also be provided. And probably most importantly, the features must be integrated into the wiki.
The good news is that, despite the somewhat bleak picture painted in this piece, the Foundation does finally seem to recognize some of the big, scary, and difficult problems editors are facing. These problems are now receiving attention and resources. But there's the question of follow-through: Will the Foundation continue to abandon software behemoths? Will VisualEditor be the next LiquidThreads, and Wikidata the next FlaggedRevs?
To its credit, the Foundation has been snapping up every available Wikimedian with an interest in this area of work. A number of trusted and respected Wikimedians now work for the Foundation, easing concerns that it's out of touch with the editing community. Even old hands such as James Forrester and Brion Vibber have now joined or rejoined the Foundation, signaling good forces at play.
There are a lot of smart and dedicated individuals both in the Wikimedia editing community and working for the Foundation who want to see good changes happen. MediaWiki is a classic jack of all trades, serving no project well, a few projects passably, and most projects poorly. But despite ill-fitting and antiquated software, Wikimedians have created amazing content. With better tools (such as a fully functional visual editor and a sane communications infrastructure), there will be even better content. The Foundation understands this; the question is whether we'll see the fruits of its labors. Wikimedians need to remain vigilant about how resources are used, and they need to question the Foundation's output. There needs to be more dialogue and engagement between the community and the Foundation.
Discuss this story
Comments begin
Ed. note: I cleared the talk page while publishing, per our standard practice. The (substantial) early comments are viewable here. Thanks, Ed [talk] [majestic titan] 08:00, 21 August 2012 (UTC)[reply]
I've been a Wikipedian since 2005, the editing interface is the same. What browser did you use then? What were your expectations? Facebook, twitter, Google, see how they've moved on since 2005. See how publishing is now easier than ever before, and then see how Wikipedia seems to have been left out. Take a look at the real time notifications on every other website in 2012, and then look at how Wikipedia works. The foundation should just move forward, the design by committee bureaucratic bullshit only takes us around in circles. Stop asking what the people already editing want and go for the blue ocean. Because when you ask what editors want, you end up with a 2 month flagged revisions trial. - hahnchen 12:33, 21 August 2012 (UTC)[reply]
On Bawolff's first point, yes indeed, developers are not mind-readers. Developers and end users often do not even speak the same language. Discerning and translating the user's wants and needs into functional requirements is a non-trivial task requiring sophisticated skills; and in my experience it is best achieved by developers meeting the users where they live, rather than the other way around.
On Bawolff's second point, generalizations about the interpersonal skills of developers in general are, at best, generalizations about something in which there is a high degree of variability. When I visited the MediaWiki wiki a few years ago, I was treated with a level of rudeness that would never be tolerated in a face-to-face professional meeting between developers and users. Seriously, people have been sacked for that. I never went back. ~ Ningauble (talk) 17:17, 22 August 2012 (UTC)[reply]
By the way, enwikipedia isn't what is primarily on my mind either, though it looms large. Actually, I am primarily (~90% of edits) a denizen of a non-pedia sister project, where new developments tend to pop up out of the blue. One of the reasons I regularly follow the Wikipedia Signpost is to discover things that might impact other projects, and I am grateful to the reporters and editors who make it happen. ~ Ningauble (talk) 15:16, 23 August 2012 (UTC)[reply]
Thanks for the detailed editorial, Mz. As general background for anyone participating in the discussion, I would encourage folks to review the 2012-13 engineering goals. It’s possible to divide these overall goals, and past engineering efforts, into three categories:
It’s great to see strong (often silent) support for the first category from everyone and some support for the second category. It’s not at all surprising that the third category (features like Article Feedback, Moodbar/Feedback Dashboard, WikiLove) is causing the most friction.
WMF has aligned itself a bit more clearly along those three categories by designating an experimentation team (the "E3" team, for editor engagement experiments) first and foremost to the third category, while having most standing teams (like the Visual Editor team) or fully dedicated individuals working continually in the first and second categories. With regard to experiments, this allows for shorter iterations (like the recent two-week post edit feedback experiment), and a standard procedure for terminating experiments that are wrapped up. This also creates a more systematic check-in point, internally and with the community at large, about whether a certain experiment is worth pursuing as a bigger project.
Why pursue these projects at all? The working hypothesis we’ve been operating under - a hypothesis that you are free to disagree with - is that this third category of change holds a lot of promise to transform Wikipedia and Wikimedia’s other projects for the better. That hypothesis is supported by data from other projects (e.g. Wikihow), and also data from the projects you’re criticizing:
As we move forward and iterate, and discuss what’s working and what’s not, I would request that we engage in an evidence-based conversation. Yes, it’s easy to dismiss anything that’s experimental or whimsical (e.g. MoodBar) based on personal dislike of elements of the user interface or the language used, or an immediate reaction to the perceived signal/noise ratio. But Wikipedia has plenty of examples of whimsy in its community (cf. userboxes, and remember that WikiLove pre-dates its software implementation), and plenty of examples of contribution mechanisms with low signal/noise ratios (cf. IP edits). What matters is whether we're successfully supporting, building and growing a community that's dedicated to developing the encyclopedia, and our other projects -- and that's very much a question that's answerable with facts and data.--Eloquence* 22:16, 21 August 2012 (UTC)[reply]
I dunno about anyone else, but I think it would be a really bad idea if everything WMF wanted to implement into MediaWiki had to first obtain a clear consensus at every project. WMF has to take into account the potential opinions of potential new editors, not just the current editing community. Powers T 23:35, 21 August 2012 (UTC)[reply]
Anyway, at least it would be better than WMF staff and developers making decisions in their own private preserves with little engagement of the broader community. (Don't get me started on how many times I have seen people with "(WMF)" in their username make edits that show little understanding of basic wikimarkup: sometimes I think the reason they don't engage on-wiki is because they don't know how.) ~ Ningauble (talk) 20:26, 22 August 2012 (UTC)[reply]
While we're on the subject of technical improvements, I've been working on a syntax highlighter that's something halfway between the status quo and VisualEditor. Feedback would be appreciated. —Remember the dot (talk) 03:57, 22 August 2012 (UTC)[reply]
Related developer discussion of this article ongoing at wikitech-l. — Richardguk (talk) 20:48, 22 August 2012 (UTC)[reply]
wishlists and budget
The WMF has sufficient budget to make a proportion of it available to community prioritised development. The problem in my experience is not that the devs lack development skill, its just that the projects they are assigned to are either tangential to the community needs or even sometimes in opposition to them. If the WMF were to make 20% of its developer budget available for community requested and prioritised needs then we could get the changes needed to make a step change improvement in the project. As for editor retention, the very act of entrusting a proportion of the development budget to the community would directly address two problems; It would give editors real hope that some of the clunkiness will be fixed; And it would reduce the current problems of active editors eventually realising that they were ultimately seen as users of the site rather than editors. ϢereSpielChequers 13:00, 26 August 2012 (UTC)[reply]
- I'm not so keen on a fixed percentage, but on closer engagement between the community and the techs: we need a noticeboard. In terms of the massive increase in tech budget and staffing this year, I'm wondering whether the mix of junior to senior, the overall salaries on offer (given the Silicon Valley drought that the foundation drums on about in its Annual Plan 2012–13), and the overall skill-profile of the engineering department, are appropriate to the needs of the movement. Tony (talk) 13:36, 26 August 2012 (UTC)[reply]
- Related: <http://www.quora.com/Wikipedia/Are-Wikipedia-software-development-engineers-of-the-caliber-that-could-work-as-SDEs-at-Google-Facebook-Amazon-etc>. --MZMcBride (talk) 13:49, 26 August 2012 (UTC)[reply]
- That is a great article. Thanks for linking to it. I have seen that energy in other movements, too. One thing I read from the article though is that even though the work is inspiring we may have burnt out many workers due to the workload. We need to hire more tech people. There are so many basic features and bugs people have been asking about for years that have not been dealt with. --Timeshifter (talk) 20:08, 26 August 2012 (UTC)[reply]
- @Tony, a fixed percentage is a pretty blunt instrument, and one that I'm confident would go away fairly quickly once everyone realised that IT developments that the community wanted and thought worth prioritising would be a better investment than ones that derive from the current process. But asking for a small minority of the IT budget to be spent on community prioritised developments is the sort of modest request that might possibly succeed. Of course it would be better if we could revolutionise the whole Wikimedia development process, I just think that a two step process would be more likely to succeed, if only because the WMF will find it hard to argue against the first step. ϢereSpielChequers 14:43, 26 August 2012 (UTC)[reply]
The problem at Wikipedia is that there is no good way for the WMF to seek ideas about a proposal, and no good way for the community to provide ideas regardless of whether the WMF sought them. For example, mw:Flow is a proposal to replace all talk pages with some new system—a gigantic proposal, yet I am not aware of any community involvement (is there a discussion somewhere; the previous link shows little activity). The design document (at previous link) has an example with avatars and watch/unwatch links, but there is no mention of fundamentals—an easy way for inappropriate content to be removed, and for unproductive discussions to be collapsed. Whatever the intentions of WMF staffers, various comments make it appear that success is measured in terms of number of participants—a bigger number justifies the WMF's budget. That's good at Wikia, but enabling forum chatter at Wikipedia will send the community the way of all Internet forums, with negative effects on the encyclopedia and the community who build and protect it.A budget for community projects would not help the fundamental problem of the WMF getting realistic feedback early during development cycles (yes, there would be a lot of noise, and somehow that would have to be dampened). Johnuniq (talk) 04:50, 27 August 2012 (UTC)[reply]
Wikia ties: Another conflict of interest for Wales
Jimbo Wales often uses his association with Wikipedia to speak on political issues, such as the SOPA legislation. It is clear that his association with the for-profit Wikia is a conflict of interest, and he should stop appearing as a Wikipedia or WMF spokesperson. Kiefer.Wolfowitz 14:32, 28 August 2012 (UTC)[reply]
Proposal for a Village Pump using DPLforum or other subpage discussion software
See:
Portuguese Village Pump allows watchlisting of individual discussions
See:
If wikipedia sinks, it wont be so bleak a thing.
Wikipedia is usually but not always trustworthy for pure Science / Math articles etc, but caveat emptor. As for social articles: it always had a right-wing bias: Its coverage of Palestine issues and issues involving male chauvinism stunk, stink and will always stink - with the tokenism of 'some critics have said otherwise'.
It is still *much more* male chauvinistic than encyclopedia Brittanica's 1953? edition (what is known as scholar's edition). And stereotyped about islam etc [even when 'praising it']. Wikipedia Much more informative, but very much more misinformative, if I may coin a word.
On progressive issues wikipedia is not worth as much as some of you might think folks, admit it! Who cares; if Wikipedia loses credibility thee are other sources. And anyone with half a brain *never* accepots wikipedia info blindly; always coss checks and uses their personal awareness of the world. It is like reading any mainstream newspaper - say NYT or Guardian [UK] or International Herald Tribune: intelligent readers cultivate reading between the lines. And they use that experience while accessing wikipedia too.
forgot to sign, sorry. Manojpandeyanarchocommunist (talk) 19:26, 29 August 2012 (UTC)[reply]