Wikipedia:Reform of WikiProjects

Background

WikiProjects serve an important role within the Wikipedia editorial community, being the default gathering points for editors interested in a particular topic area. Their function, in practical terms, is twofold:

1. WikiProjects function as centralized discussion areas for issues concerning their chosen scope; this includes things such as guideline development for articles under their purview.
2. WikiProjects also function as centralized areas for collaborative processes, such as article quality assessment and peer review.

Scope and critical mass

The extent to which a project can successfully fulfil both of these functions depends largely on its choice of scope. The more effective projects are generally those whose scope attracts a sufficiently large and cohesive community of editors. Projects with scopes that are too broad or too narrow tend not to function as well.

Extremely broad projects, such as Wikipedia:WikiProject History, are generally entirely dysfunctional. The scope is so large that most potential members simply don't share any substantial common interests—and those that do will typically interact through more focused sub-projects; thus, both WikiProject functions break down. This is unavoidable, to some extent; it seems that the core topics are simply too general to sustain a cohesive editorial community.

Overly narrow projects, on the other hand, such as Wikipedia:WikiProject Marillion, typically have little problem acting as discussion areas; but the extent to which they're seen as having the legitimacy to serve as forums for, say, guideline development is debatable. Furthermore, small projects generally have neither a need for dedicated processes of their own nor the manpower to keep them active; a project covering a hundred articles, for example, gains virtually nothing for the effort of creating and maintaining its own peer review process.

There is no obvious benchmark for when a project is sufficiently broad that the benefits of having internal processes are worth the effort to create and maintain them, but practical experience suggests that complex internal processes are not worthwhile for projects covering less than a thousand articles.

In brief, there is a certain range of scopes for which the existing WikiProject model is a good fit; projects broader in scope than this likely require a completely different approach, while narrower ones don't need all the features that have been adopted for WikiProject use, and may function more efficiently with a leaner structural model.

• 2016 update: Despite the above charge of dysfunction, the largest project remain large and active, and large number of small-to-middling projects have died (though others remain very active). Most of the "mega-projects" have been productive in various ways; despite the lack of common highly topical interests, the participants in these larger efforts often need and thus develop tools in common, which has been a boon. And some of their output has been influential. WikiProject Medicine's WP:MEDRS essay on reliable sources for medical information has become accepted as an important guideline, various sports projects have developed tournament bracket templates and other coding of great complexity, the biography and military history projects have brought a remarkable degree of consistency of approach to several classes of article; and various science project have well-covered their areas with regard to most key concepts, figures, and events.

  Nevertheless, it is correct that many of the broadest-scope projects are editorial ghost towns, with most work happening on a much narrower topical basis; e.g. WP:WikiProject Tree of Life gets very little done as the high topical level, despite constant activity on much narrower topics, like orchids or animal breeds or viruses.

  Not much has changed, overall, since this reform was first proposed, other than the general editorial decline after the "gee-whiz" boom of WP's rise. Now that the mountain has be climbed, a lot of people are going home, as it were. One completely different approach has been the revitalization of old "collaboration of the week" style efforts into a new Wikipedia:Today's articles for improvement (actually weekly), drawing together user-talk-page subscribers to the TAfI alert to wiki-flashmob an article in need of attention, often more than doubling it in size and citations in a matter of hours. More projects have taken up the delivery of newsletters, though their maintenance, like those of WP:PORTALs, requires a lot of dedication (and a large number of portals are now moribund). Generally, specific calls to editorial action appear to have some positive effect, whether it be to improve a stub, or push and article to GA/FA.

Task forces

One approach developed to improve the function of narrowly-scoped groups is that of the "task force". A task force is essentially a semi-autonomous component group of a WikiProject that allows editors with a narrower interest to have a dedicated area for their work, but attempts to eliminate bureaucratic overhead by relying on the parent projects processes and technical infrastructure rather than creating its own. For example, a typical task force does not have a project banner in its own right; instead, it relies on a parameter in the parent project's banner (which is constructed so as to generate features such as assessment statistics for the task force without the need for additional effort).

Task forces may be jointly operated by several (commonly two) WikiProjects; see, for example, WP:MILAIR. This typically occurs when it becomes useful to have a central location for considering issues that lie at the intersection of two project scopes.

• 2016 update: This is basically how WP:WikiProject Council/Proposals handles this now. As a general rule, if it can be a taskforce/workgroup, they strongly urge that it be one, because small projects so often die off quickly, and they tend to drain editors from larger, better organized ones and diffuse their efforts, while keeping people in working groups within a taskforce helps preserve activity in the larger group, as well as recruit attention to the needs of the smaller one.

Current problems

The application of the current WikiProject model (and, in particular, all of its associated technical and procedural features) to all levels of groups has resulted in several problems.

Over-tagging

An obvious negative consequence of proliferating WikiProjects is that the common practice of projects adding talk-page banners to articles within their scope results in ever-increasing numbers of such banners on every talk page. While this may seem sensible in some cases, the hierarchical nature of many projects can result in long "chains" of banners; for example, an office building in Houston might be tagged by the Houston, Texas, United States, Skyscrapers, and Architecture projects. Because, in many cases, these banners are used to provide practical functionality (most notably, article assessment tracking and statistics) to the projects involved, simply removing them has negative consequences for the projects; but few are set up to provide that functionality to parent or child projects, meaning that the entire chain needs to be in place.

• 2016 update: See § Tagging proposal, below.

Redundancy and fracturing

Another concern is the creation of WikiProjects that have highly inter-related scopes due to splitting by type of article rather than topic. For example, the Albums and Songs WikiProjects cover largely the same material, and are populated by largely the same editorial community; but the separation means that discussions are split over multiple pages. This only becomes worse as formal processes are independently developed by the overlapping projects; if a process requires a certain critical mass of editors to function, but the available manpower pool is split among several overlapping processes, the likely end result is that none of them will actually be productive.

A somewhat broader concern than pure redundancy is the fracturing of discussions and efforts due to related projects not interacting, or even being entirely unaware of each other's existence. This manifests most obviously when contradictory guidelines are adopted by such groups of projects, but can also appear as redundant template development, inconsistent category schemes, and other practical problems.

• 2016 update: See § Task forces, above. There's now strong resistance to the creation of new "fractured" projects. However, very little has been done to merge existing active projects. There seems to be a sense of "leave well enough alone". A case in point was the formation of WP:WikiProject Women in Red at a WikiConference, to focus on missing articles on women (i.e. red links), and poor or biased coverage of women on WP generally, a proposal to merge all the women-related projects and task forces, or even make them daughter projects and mutual working groups of the new ones, failed to gain consensus. Instead, they've been declared "affiliates" of the project, and are listed in a sidebar on its project page. Whether this will be an effective collaboration model remains to be seen.

Reform proposals

Tagging proposal

It is proposed that {{WikiProjectBannerShell}} (or a suitable derivative, to be developed as desired) be generally adopted for talk pages with more than some arbitrary number (perhaps two or three) of WikiProject banners. This will alleviate the major concern with excessive templates, while at the same time allowing legitimate multiple tagging of articles that are of interest to several projects.

• 2016 update: This has become the working standard. It is now totally uncontroversial, even completely expected, to collapse two or more project banners into a {{WikiProjectBannerShell}}.

WPfD proposal

As a method of addressing the above issues, it is proposed to create a WikiProject for Discussion process similar to the AfD process. Any editor is able to nominate a WikiProject for discussion. The community at large will discuss the WikiProject in question, hopefully reaching consensus. That consensus could be to keep the WikiProject as is, merge the WikiProject into another WikiProject (perhaps as a task-force), or delete the WikiProject and its associated banners. Similar to AfD, the discussion would last a week or until consensus is reached.

Also similar to the AfD process, a discussion could only be deemed "closed" by an admin, who would then be responsible for adding a tag explaining the consensus to the WikiProject's talk page.

If consensus is to keep the WikiProject, nothing else needs to be done.

If consensus is to delete the WikiProject, it would be added to a category or list of those who's banners need to be removed. A specific bot (or perhaps any available bot) would be requested to run the needed programs to remove banners. Once that is done, the project pages would be deleted (by an admin) and removed from WP:1.0 and any other places needed.

If consensus is to merge the WikiProject into another one, both WikiProjects would be notified and the two communities would have to merge. This may be better accomplished by a rename (see below).

If the consensus is to split the WikiProject into multiple projects, then the pages would be cloned to the new name(s)

If the consensus is to rename, then that change is made. This includes both:

• "Re-purposing": changing the name, goals, and/or scope of a WikiProject; an example would be the proposal to change the World music WikiProject into a Regional and National music WikiProject
• "Re-tiering" (or "task-force-isation"): an example would be the Jesus WikiProject becoming the Jesus taskforce of the Christianity WikiProject

Technically, different criteria would be used – for example, guidelines for when a Wikiproject should be split would be based on the number of tagged articles rather than the size of the project page.

Rebuttal

Too complicated, too forceful, likely to lead to bad feeling. See Wikipedia_talk:WikiProject_reform/Archive_2#WPfD:_Banners_are_the_most_pressing_issue.2C_not_Projects for comments and a simpler scheme; it's premature to edit them into this section of the essay at this stage.

Process

1. Templates are posted, notifying associated parties of the proposal, and discussion is solicited
2. Consensus is reached before changes are made

Updates on such proposals

• 2016 update: No such process emerged. However, WP:Consensus can form anywhere, and it is not unknown for either WP:WikiProject Council/Proposals or WP:Miscellany for discussion (which has long played this role) to merge moribund projects into larger ones. This process could be encouraged and somehow more formalized, but there is no extant proposal to do so.

See also

• Wikipedia:Reforms
• WP:WikiProject Democracy