User:Pi zero/essays/vision/wikinews

This essay is under construction.

Here is an overview of the path I see to Wikinews growth, moving forward, with emphasis on its feasibility. The short-short version:

A really successful wikimedia sister project needs two things: idealistic goals that can inspire passionate volunteerism, and means to tap into the long tail of small-sized potential contributions. Wikinews has no deficit on the first point, and on the second there are structural reasons to believe major gains can be made by means of semi-automation.

Ideals

Any volunteer project is fueled by idealism. Idealism is the one thing that can motivate passionate volunteerism, which is what you need for a successful volunteer project. So one of the essential questions to ask about any volunteer project is, what are its ideals?

Grass-roots information providing

While each of the wikimedian sisters has some of its own characteristic ideals — more about some of those in a moment — there is a base of ideals common to all the sisters. Not the Wikimedia Foundation's "mission"; that isn't about ideals, it's just one abstracted facet of what the sisters do, lacking why and some crucial parts of how. The common idealism of the sisterhood, as I understand it, is that information providing, being crucial, should be in the control of The People.

This particular form of idealism presents two problems for — or with — the Wikimedia Foundation: as a promoter of the sisterhood, and as a technical facilitator of the sisterhood.

The promotion problem is very simple (and thereby unavoidable): Recruitment for the sisters is based on the perception that contributors are empowered because they are of The People; the Foundation is the antithesis of this empowerment, a centralized NGO asking volunteers to voluntarily give away their power to the Foundation (rather than the Foundation devoting its power to further empowering The People). So the more Wikimedia tries to promote the sisterhood, the more it undermines the prime motive for the sisterhood's volunteers.

The trouble with the Foundation as a facilitator is that they keep approaching software design by first arriving (somehow or other) with a notion of the specific tasks to be performed and then putting expert software developers to work on creating software for those specific tasks. This is guaranteed to produce software that damages the sisterhood in the long run — but the most fundamental reason it is guaranteed to do so is not the most obvious problem with the process.

The fundamental problem is that software developed by a centralized cadre of specialists to support particular tasks is inherently disempowering to the volunteers. Every time the Foundation tries to do this, it systematically detracts from the empowerment-of-The-People that should be the sisterhood's ultimate reason for existence. The centralized developers cannot get accurate or rapid feedback from the volunteers whose perspective defines what is wanted; and cannot respond agilely even if it were possible for them to get such feedback, both because bureaucracies have a lot of momentum and because software to support specialized tasks is naturally inflexible. The volunteers are pushed into doing what the specialized software says they should want to do, and anything different they might want, whether in small details or large choices of task, requires a massive and inefficient process of trying to get through to the centralized bureaucracy and then waiting for a very long time before, eventually, the centralized bureaucracy might respond — which might or might not be something like what was wanted.

This is particularly ironic because the alternative to this centralized model is not only known, it's the single most prominently visible thing around here: wikis. If you see a small or large problem with a (non-archived) page on a wiki, you don't fill out a cumbersome form to petition a centralized bureaucracy to fix the problem, and then spend months of back-and-forth negotiation trying to explain just what you have in mind; you just do it. That's why wikis work, this no-hassle tweaking by ordinary folks. Even if there is one or another form of community approval involved, the approval is distributed (and preferably should follow submission); there is no centralized, clumsy, outside authority in the way.

This requires a profoundly different procedure for developing the underlying software. It's like the difference between writing a software library of useful functions, and planning out the primitives of a general-purpose programming language. The language primitives are chosen slowly and carefully, to be small and easy-to-use following a consistent pattern while unleashing the programmer's (in this case, the ordinary wiki contributor's) ability to imagine things that the language designer never thought of and make them real. I've discussed some necessary technical features of such a system in another essay; ultimately one needs to strengthen wiki markup in a way that allows it to support interactive pages, which when composed become community-grown wizards. This supports the ideals of empowering-The-People in (at least) three different ways: by enabling the volunteers to build and modify such tools without asking permission from a central authority, it affirms their right to do so; by not receiving such tools from a central authority, it affirms that the volunteers are more suited to make decisions than any central authority is; and by using the community-grown tools, volunteers can become more effective contributors to the ideals (as the WMF, because of its centralized nature, is inherently unsuited for identifying and acting on specific needs of the community).

To appreciate the depth of this fundamental problem with the Foundation's software initiatives, consider how the Foundation is likely to perceive the outcomes of these initiatives. There are two cases: either the Foundation is able to see there's a problem with the initiative, or it isn't able to see the problem; and in both cases, the Foundation is distracted from the fundamentals. Ironically, this distraction is only made worse when the Foundation tries to gauge the relative success or failure of the initiatives by looking at detailed feedback about the initiatives from the volunteer contributors (keeping in mind that the problem is to be found in the fundamental big picture of the dynamics of the wiki community, which would rarely if ever appear in volunteers' detailed feedback). When it's apparent something has gone wrong, given the procedure for software initiatives that the Foundation has committed itself to — identify specific tasks, then create software for those tasks — when the Foundation gets complaints that what the software does isn't what's wanted, it's easy to blame this on the process by which the specific tasks were identified; it would be much harder for a centralized organization, with its natural bureaucratic momentum, to recognize that it was a mistake to try to address specific tasks at all.

The fundamental problem is even harder to recognize — and therefore the mistake becomes even more entrenched — in cases where the Foundation gets positive feedback. Consider the fate of an existing system. There are sure to be flaws in it (if it exists, it has flaws). It's very difficult to improve an existing system, finding ways to enhance power without breaking existing uses or compromising simplicity or easy of use, and a centralized bureaucratic organization may not be agile enough for the task. So suppose the Foundation chooses to not improve the existing system, and instead they commit themselves to an elaborate project to add on something inherently separate from the old system. Naturally, this takes a long time, during which the existing system probably gets no worse (unless the Foundation neglects its responsibility to maintain the existing software) but the existing system probably starts to seem worse since other software platforms around it are being improved while the Foundation's system stagnates. When the Foundation's addition finally comes on-line, it can scarcely help being perceived as an improvement, and it may even be a short-term improvement when compared to the alternative of never making any improvement to the existing system as it was before the Foundation's software initiative was started. That's not the right thing to compare it to, though. One should be comparing the new state of things, as the Foundation has caused them to be, with what could have been if the Foundation had improved the existing system instead of adding on something separate. The new state of things has taken the existing system (which in this case is wiki markup, whose advantages are the primary reason wikis have been successful at all) and, instead of strengthening it, has weakened and undermined it by leaving flaws in place while making the whole much more cumbersome through division into separate parts (not forgetting the increasing software maintenance effort needed for an increasingly complicated system). Yet the Foundation receives positive feedback. (Good intentions gone awry, indeed.)

Wikipedia's handicap and Wikinews's edge

Wikipedia and Wikinews provide different kinds of information, with different characteristics, placing different technical constraints on they way they can operate. Broadly: Wikipedia provides encyclopedia articles, articles of summary historical information about things; which favors putting something up and then improving it over an unbounded period of time, with whatever level of protracted debate or squabbling contributors feel like devoting to it ("there is no deadline"). Wikinews seeks to provide news articles, neutral-and-accurate snapshots in time of what is known about a current event at the time it occurs; which calls for getting things right the first time and publishing all in a very short period of time, then archiving it as a permanent record of what things looked like at the time. The dynamics of these two sorts of tasks, and in particular the dynamics of how wikis go about them, are profoundly different. Less obvious is the way these different goals and dynamics interact with the policies and social structure of a wiki.

Neutrality
Civility/AGF

Strategy across different-language Wikinewses

nature of the news challenge
project evolution path

Tactics on English Wikinews

contribution packet size
logistics of timely review