Cost vs Benefits of Wikiprojects
Cost vs Benefits of Wikiprojects
I would submit that Wikiprojects, like many other "features" of Wikipedia, were created without a clear cost/benefit analysis, and now survive and multiply largely by the blind physiological growth-drive of any bureaucracy, rather then by their actual value for the Wikipedia project. A few months ago I posted some statistics on one randomly chosen Wikiproject to the Wikiproject Council forum. I may have been very unlucky, but based on that single sample and less systematic observations I am inclined to believe that:
- Only a very small percentage of the listed members of a Wikiproject actually make significant contributions to the project's articles.
- Significant contributions to those articles were are by editors who were not members of the Wikiproject.
- The production of "good" and "featured" articles in an area is not significantly enhaned by the creation of a Wikiproject on that area.
- Raising an article to "good" or "featured" status requires intense work (several hundred edits over a couple of month), almost all of it by one, with little or no contribution from other Wikiproject members.
- The editors who most contribute to said articles are self-motivated, and are neither marshalled not guided by the Wikiproject.
Thus I would claim that the contribution of the Wikiprojects to Wikipedia is largely illusory: they do not generate or promote good work, they only passively receive credit for any work done on "their" articles -- work which would be done even if the Wikiprojects did not exist.
On the other hand, Wikiprojects have several significant costs:
- A significant amount of editor work is spent in bureaucratic activities (tagging, classifying, and grading articles, writing guidelines, editing the project's page, designing navboxes and infoboxes, etc.)
- More editor time is wasted (by members and non-members alike) on reading Project guidelines.
- If (and to the extent that) Wikiprojects are effective, they encourage "tribalism", the fragmentation of Wikipedia's editor base into communities with divergent goals. Namely they augment an already worrisome tendency of articles getting written not only by the "insiders" of a topic but also for those "insiders". Thus articles on Christianity topics end up being written for Christian readers, articles on anime for anime fans, articles on chemistry for chemists, and so on. This tribalism results in articles whose language, arrangement, and perspective are inadequate for general readers, who presumably are "outsiders" for the most part.
- The article grading scheme operated by the Wikiprojects was inherited from the Wikipedia-1.0 project, and encourages editors to work towards the goals of WP-1.0, instead of those of the "real" Wikipedia. Specifically the grading scheme offers psychological rewards for the editor who spends a couple of months producing a single "A"-level article, and no reward at all for the editor who puts the same effort into bringing 100 articles from "C" to "B" class. Yet it is these, and not the "A" articles, which are most useful to the readers.
My negative views on the worth of Wikiprojects stems ultimately from the huge discrepancy between the amount of work that needs to be done (over 3,000,000 articles in the English Wilipedia alone, almost all of them in need of expansion or cleanup; plus sevral million of articles that ought to exist but don't) and the number of editors who would have to do that work (depending on how one counts, less than 10,000 people, and shrinking). If a team of 10 volunteer janitors get the assignment of keeping the Pentagon building clean, there is no management structure or overseeing mechanism that would get them to work more (or more productively) than simply letting each janitor roam the building at random cleaning up whatever mess he finds. On the contrary, if any of those janitors were to be diverted from random cleaning work to management or evaluation activities, the only result would be a drop of 10% in the team's prouctivity.
So I would urge Wikipedia's administrators to take a closer critical look at the cost/benefit ratio of Wikiprojects in general; not merely enumerating expected benefits but trying to quantitaively measure the actual benefits. All the best, --143.106.24.25 03:33, 21 January 2010 (UTC)
Just signing the previous entry: Jorge Stolfi (working mostly in the English Wikipedia).
Actually, I think that this evaluation is overly optimistic. The danger of Wikiprojects is not so much that they siphon off effort which otherwise would have been a contribution towards the goal of the overall project. It is not necessarily the case that the time spend on bureacratic activities would otherwise have been spent on article quality (after all every user decides for himself how much time he spends on what activity) or that if the time were to be spent on articles it would lead to an improvement in quality.
The danger of Wikiprojects is that they may form independent communities, each with their own distinctive community values (bias, etc), and that they may work at cross-purposes from what the overall project is trying to achieve. The focus should be outwards, on reality, on actual knowledge and on how to make it accessable. Once there is a community the risk is that the focus turns inwards, playing the community game; then the overall project loses out. - Brya 06:46, 22 January 2010 (UTC)
This definitely occurs, with the projects forming strong communities, lobbying acceptance of policies, going all together to deletion reviews etc. But I expect that with the increase of the project mass these effects become less pronounced, whereas the availability of expert to comment/help creating/help improving articles increases.
Dear Jorge Stolfi,
If I assume that the goal of a project is to create FA or GA articles, and assume that FA and GA are good indicators for the amount of quality, than I agree with you. However, I don't think either one of those assumptions is necessarily true.
The task force for quality has recommended to bring the Wikiprojects of diferent Wikipedias together. The reason behind this is not to stimulate the production of FA articles, but to encourage discussion and enquiry. The projects should be the platforms where specialist users meet to find areas where the coverage is lacking, answer questions from other users and try to give their work some direction. Also, they should try to establish what aspects like "verifiability", "balance" and "neutrality" mean for their particular field.
Dear Woodwalker, My concern is broader and more basic than "whether Wikiprojects are producing FA/GA articles". The fundamental problem that I see (of which Wikiprojects are only one facet) is the lack of any conscious effort within Wikimedia to prevent "rampant featuritis" and bureaucratization.
As things are now, any editor can invent a new Wikipedia "feature" (guideline, template, navbox, infobox, wikiproject, category, portal, task force, whatever), and start using it on articles. Then other editors see that "feature", assume that it is "official policy", and start using it themselves, believing that doing so "good citizen"'s work. That is how we got stub tags, categories, editorial tags, "main article" templates, infoboxes, navboxes, citation templates, en-dashes in article names, wikitable syntax, the "articles for deletion" page, Wikiprojects, the Wikiproject Council, Wikiportals, format-tweaking robots, and much more --- including the vast ocean of pages in the Wikipedia:* namespace.
Every one of those "features" has a huge cost: not only the editor work that is diverted from content creation to formatting, classifying, tagging, sorting, and debating, but also the loss of editors, new or old, who are put off by the increasing complexity of the system. The latter, alas, is almost invisible. (Statistics indicate that the editor base, which had been doubling each year until 2005, has been decreasing since 2006 with a half-life of 4--5 years. It seems that since 2006 practically no new editors have joined, and old editors have been steadily dropping out. I wonder whether Wikipedia planners are aware of those numbers?)
The problem is that none of those "features" went through a critical cost/benefit analysis. Unfortunately Wikipedia has neither the tools nor the organizational structure to do such an analysis. It also lacks any mechanism that could reduce its complexity and eliminate counterproductive features. Ironically, it has a mechanism for deleting *articles* (and a subset of editors who apparently enjoy doing that, and do it a lot); but it has no mechanism to delete *features*. Essentially, once a template has been used in a few hundred articles, it is practically impossible to delete; and the same goes for all other features. Can you imagine a corporation that allows each employee to start or join as many projects as he wishes, does not perform any per-project accounting, and is unable to stop a project that cannot bring revenue? Well, that is Wikiedia...
I firmly believe that if *any or all* of the above features were suddenly deleted, Wikipedia would become a much better encyclopedia, and editors would become more efficient and satisfied. All the best, Jorge Stolfi --143.106.24.25 09:43, 22 January 2010 (UTC)
See also this proposal. - Brya 05:35, 23 January 2010 (UTC)
Dear Jorge Solfi,
This is indeed a concern. Tagging articles with what you call features is part of what I call "maintenance edits". I agree that such edits may have negative indirect effects on community health/happiness. I can recommend you to read this essay by Sjc. On the discussion page, I made a comment about "maintenance-driven policy" and my fear that this discourages good editors. The problem we discuss here is slightly different, but similar.
I do agree that creation of new "features" is too easy in the current set-up. In my view however, maintenance edits aren't a primary task of wikiprojects.
From my own experience, the real problem of WikiProjects is that most of them are essentially inactive. I do a lot of gnome work and when I spot problems that I can't solve, I try to notify the relevant project. That seemed like a pretty good strategy when I started but in most cases, it turns out to be a waste of time since project members either don't watch the talk page or don't actually respond to these requests. Writing GA and FA is nice of course, but it's equally important for a project to take routine care of its articles and to take on less glamorous tasks. It's symptomatic of a more general weakness of the project: there are very few mechanisms in place to report problems requiring the help of a competent editor.