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.
 | |
  | |
  | |
| The first prize in the previous core contest was won by Guettarda for improving Ecology. The topic involves the full scale of life, from tiny bacteria to processes that span the entire planet. Ecologists study many diverse and complex relations among species, such as predation and pollination. |
The Core Contest is a month-long competition among editors to improve Wikipedia's most important "core" articles—especially those that are in a relatively poor state. Core articles, such as Music, Computer, and Philosophy, tend to lie in the trunk of the tree of knowledge; by analogy, featured-and good-article processes generally attract more specialist topics out on the branches. Casliber, the main organiser of the contest, told the Signpost that "core articles present particular challenges in their broad scope, conceptual difficulties, and the balancing of comprehensiveness with Wikipedia's limits on article size." Nevertheless, he says, core articles are an essential part of an encyclopedia, are popular with readers, and serve as launchpads to more specific articles."
The first core contest ran for two weeks in late 2007, and the second for three weeks in March this year. For the March contest, Wikimedia UK kindly donated £250 in Amazon vouchers, which were shared by six editors. The first prize went to Ecosystem, improved by Guettarda, and the second prize to Ealdgyth, for Middle Ages. We asked Ealdgyth what problems she faced in improving an article on such a huge topic:
The biggest challenge was figuring out what not to include. Unlike most of my articles, where I start with nothing much more than a stub, there was already a pretty substantial article at Middle Ages; so I had to verify that information and cull out large chunks of unduly weighted information—for example, there was an extensive discussion of Hungarian late medieval history that was clearly unbalanced in the context of the article.
Balancing and weighting is always difficult on a big topic. No matter what you do, someone has a pet theory that they want included! In this case, I had to negotiate whether—contrary to most sources, which consider the Middle Ages a purely European subject—the article should cover the whole world.
The referencing I deployed on Middle Ages is a bit different from what I'd normally use: I went with much broader and less specialized works; so instead of journal articles and monographs, I used a lot of college textbooks and wide-scope histories. This helped to keep the balance and focus of the article on the broad sweep, instead of the minutiae of the various subtopics that are, anyway, better covered by daughter articles.
The original 2007 contest focused on producing new articles; consistent with the maturing of the English Wikipedia, this year's contests instead reward the improvement of existing articles rather than the creation of new ones, with a priority to lift the standards of articles in poor shape. The current event started on 1 August and will finish 31 August, Saturday week. It was felt that four weeks would lead to a more inclusive event, which seems to have been confirmed by increased participation: with a week and a half to go, 18 nominations in the running, up from 10 in March. The UK chapter has again funded the prizes.
Casliber told us that it's definitely not too late to enter, provided new nominators are willing to put in a bit of time: the judges want to choose from as many eligible items as possible. Editors select from lists of vital or core articles, although if they give an acceptable rationale they're welcome to nominate a broad or important article outside these two lists. A priority is to improve those core articles in the worst state of disrepair.
After the close of the contest, a panel of judges—Casliber (talk · contribs), Brianboulton (talk · contribs), Steven Walling (talk · contribs), and Binksternet (talk · contribs)—will weigh up the improvements made and the "core-ness" of the article, to determine the "best additive encyclopedic value" to Wikipedia. The judges and other editors are already providing feedback on the wide range of articles represented among the entries, which include Sculpture (entered just three days ago), Transport, Marie Curie, Language, Alps, and Indian subcontinent. Signpost readers are encouraged either to consider making a late run for the gate or to contribute helpful feedback for contestants.
The winners and prizes will be announced in September. For editors who would like to enter the competition, the rules are on the main page of the contest.
OpenGlobe, a fork of Wikinews started last September (see Signpost coverage: 12 September, 19 September), has gone offline.
OpenGlobe was forked from Wikinews (WN) by several contributors who felt that the approval process on WN was needlessly complicated and bureaucratic. With a host (TechEssentials) ready to take them on, they made the final decision to depart in September 2011. The project's founder, Tempodivalse, told the Signpost that the first few months of OpenGlobe went very well.
Yet, the success belied a fatal flaw: a previous Signpost report put the number of active OpenGlobe users at nine, so losing any of them would have been a major blow. As such, the site ran into difficulty when real-life pressures after the new year forced a few contributors to stop writing. The authors left were unable to match a similar level of productivity: the number of contributors and stories published declined over the next several months until there were just two to three active authors.
This may not have been the project's death knell if OpenGlobe had been a typical wiki project, but Tempodivalse notes:
If we were running a project that wasn't so time-sensitive this wouldn't have been as big a problem. But a news site must have a constant stream of articles to present, or it will lose relevance rapidly. When only a few editors are available, the pressure intensifies to keep news coverage fresh, and burn-out is likely since you just can't be publishing stuff all the time – kind of a vicious cycle. I suspect that's what happened here.
With hardly any new content coming in, there was little incentive to donate to keep the project running. OpenGlobe could not meet its financial obligations to TechEssentials by March, and the consequent conflicts and stress drove all of the remaining contributors off the project. The site was finally taken offline last week.
In the Utah Court of Appeals this week, the majority opinion in Fire Insurance Exchange v. Robert Allen Oltmanns and Brady Blackner relied on Wikipedia for the basic premise of their legal opinion, and included a concurring opinion devoted solely to the issue of citing Wikipedia in a legal opinion.
The Signpost covered the beginning of this trend in a UK court case in 2006, and further cases in 2007. The latter was prompted by a New York Times article that year by Noam Cohen, a frequent contributor to its Wikipedia-related stories. At the time, Cohen reported that more than 100 American court cases had cited Wikipedia, including 13 from the federal appeals courts (as distinct from American state appeals courts, within each of the states). Why did the judiciary choose to cite Wikipedia? Cohen quoted Stephen Gillers of the New York University Law School as saying that the most critical factor is public acceptance, including acceptance by the litigants: "A judge should not use Wikipedia when the public is not prepared to accept it as authority." Cohen elaborated:
For now, Professor Gillers said, Wikipedia is best used for 'soft facts' that are not central to the reasoning of a decision. All of which leads to the question, if a fact isn’t central to a judge’s ruling, why include it? "Because you want your opinion to be readable," said Professor Gillers. "You want to apply context. Judges will try to set the stage. There are background facts. You don’t have to include them. They are not determinative. But they help the reader appreciate the context." He added, "The higher the court the more you want to do it. Why do judges cite Shakespeare or Kafka?"
By 2008, the number of American court cases that cited Wikipedia had quadrupled, prompting commentary from Professor Lee Peoples, who concluded in the Yale Journal of Law & Technology that much caution is needed in citing Wikipedia because of web-page fluidity and the multiple issues inherent in a page freely editable by anyone; but in his view, it could be acceptable in "in some limited situations for defining slang terms and for getting a sense of a term's common usage." (more below)
The practice has continued. This week, the Utah Court of Appeals issued a 12-page ruling in Fire Insurance Exchange v. Robert Allen Oltmanns and Brady Blackner—which included a five-page concurring opinion from Judge J. Frederic Voros, Jr. specifically dedicated to the issue of citing Wikipedia in law decisions.
Voros quoted extensively from Peoples' 2008 study. Voros recognized the problem of Wikipedia's fluidity and quoted Peoples' study: without "a date- and time-specific citation, researchers who pull up a Wikipedia entry cited in a judicial opinion will never be absolutely certain they are viewing the entry as it existed when the judge viewed it. ... This may ultimately lead to uncertainty and instability in the law." He also touched on the divide in the judicial sector over whether to cite Wikipedia or not, saying that "citing Wikipedia is as controversial as it is common", before moving into a justification for a significant citation to Wikipedia in this case.
Voros relied heavily on Peoples in crafting this portion of his opinion, noting Peoples' "bright line rules" for not citing Wikipedia in a judicial opinion, including technical or scientific terminology. He based his defense of the citation in the specific definition needed—the common meaning of "jet ski". Fire Insurance Exchange's (FIE's) insurance policy noted that it would not cover injuries that result from "the ownership, maintenance, use, loading or unloading of aircraft, motor vehicles, jet skis and jet sleds", or various specified types of watercraft.
So the lawsuit alleged that FIE did not have to compensate Oltmann and Blackner for the injuries they suffered on their personal watercraft because "jet ski" applied to any watercraft of that type. Oltmann and Blackner disagreed. Wikipedia enters the picture when "vernacular or colloquial is key to the resolution of a case"; the judges found that "Wikipedia is tough to beat" in this area. However, this was set against a scenario where a smart individual would want to "avoid a surgeon who bases his or her understanding of complicated medical procedures on an online source whose contributors range from expert scholars to internet trolls."
Voros went deeper, saying that Peoples' endorsement of "turn[ing] to Wikipedia entries for evidence of the common usage or ordinary and plain meaning of a contract term", along with similar cases that cited Wikipedia, is proof enough that a Wikipedia citation is appropriate: "Whatever its shortcomings in other contexts, for this task, an open-source encyclopedia with many editors and millions of readers seems just the ticket."
Thirteen featured articles were promoted this week:
Nine featured lists were promoted this week:
Three featured pictures were promoted this week:
New embeddable scripting ("template replacement") language Lua received considerable scrutiny this week when it began its long road to widespread deployment, landing on the test2wiki test site on Wednesday (wikitech-l mailing list).
Specifically, under the direction of WMF lead platform architect Tim Starling, two extensions were deployed to test2wiki ahead of a deployment to MediaWiki.org in the near future: Extension:Scribunto, which acts as an interface between wikitext and a backend Lua interpreter, and Extension:CodeEditor, an extension that drastically improves the edit page for Lua modules.
In terms of design, several things have changed since Lua was first mentioned in the Signpost back in January this year, but the thrust is similar. If this first deployment is anything to go by, Lua integration will mean the creation a new module: namespace in which to host Lua scripts and the introduction of an {{#invoke:...|}} parser function. Communities will be expected to use only #invoke within template space in much the same way as they currently use other parser functions such as #if.
The gains are both potentially very significant – faster template load times, plus cleaner and more powerful template code – and are largely undisputed. Talks explaining Lua were well-received at both Berlin and Washington. The only criticism from developers was that Lua, while a step in the right direction, is not the perfect solution: Can Wikimedians really be expected to learn a whole new programming language? Should there not be a central repository of Lua scripts? Might Lua not be too simple to meet wikis' ever expanding templating requirements? For now, however, developers await with cautious optimism.
For the fourth in our series profiling participants in this year's Google Summer of Code (GSoC) programme, in which student developers are paid to contribute code to MediaWiki, the Signpost caught up with Akshay Chugh, a recent electronics and instrumentation graduate working out of the Indian city of Jaipur. Originally fascinated by user interface design, Akshay Chugh has more recently turned his attention to designing an extension that can turn a vanilla MediaWiki installation into one immediately suitable for use as a "convention" (for example, Wikimania) hub.
| “ |  As of now, the dashboard page (which is where an admin will spend all of their time while interacting with this extension) works as it should, and other essential functionality, including the author registration page, is good to go. At this point it still lacks some other features such as an account setup page, internationalisation/localisation support, and a payment gateway which will probably give this whole setup a lot more meaning. But overall, I would say I'm pretty content with the end result. Needless to say, some of the things I'd thought would be pretty straightforward and easy to implement didn't turn out to be. In particular, one of my goals with this extension was to make it as generic as possible to allow its users to customize it in whichever way they want. Hence the difficulty: every decision made and every step taken forward had to be done with a sense of being extensible and customizable. During the course of this project I haven't implemented many features with performance in mind, having said that I presume many of the difficulties and mind-boggling issues are yet to come in the weeks after GSoC. |
” |
.png){kind=spacer}
Not all fixes may have gone live to WMF sites at the time of writing; some may not be scheduled to go live for several weeks.
This week, we spent some time with WikiProject Korea. Started in September 2006, WikiProject Korea covers the history and culture of the Korean people, including both countries that currently occupy the Korean peninsula. This task has proven difficult with North Koreans notably absent from the Wikipedia community due to tight control over access to external media. The project is home to over 16,000 pages, including 15 pieces of Featured material and 66 Good and A-class Articles. Project members work on a to-do list, create requested articles, update articles that are missing Korean script, and maintain a variety of working groups. We interviewed Ed! and PeanutbutterjellyTaco (PBJT).
What motivated you to join WikiProject Korea?
The project is home to 14 pieces of Featured content and over 60 Good Articles. Have you contributed to any of these articles? What are some challenges to improving articles about Korea to FA or GA status?
Does the division of the Korean peninsula into two countries impact Wikipedia's coverage of Korean topics? Are there any disagreements that arise from nationalistic or cultural differences between the North and South?
Are there any areas of Korean biography, culture, geography, politics, or business that are better covered than other areas? What topics could use some expansion?
The project has a variety of working groups. Have you been involved in any of these initiatives? Do these working groups collaborate with any other projects for which there is some overlap in subject area?
What are the project's most urgent needs? How can a new contributor help today?
Anything else you'd like to add?
Next week, we'll get caught in some wibbly wobbly timey wimey stuff. In the meantime, you'll find that our archive is bigger on the inside.
Reader comments
.svg){kind=link}