Wikipedia:Reform of WikiProjects

Please edit this proposal!

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.

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.

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.

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 others' 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.

Reform proposals

With the idea of limiting the proliferation of WikiProjects that are poorly scoped (in one way or another) and the attendant issues, a set of several reforms is proposed.

Tiered system

A distinction should be made among several "tiers" of WikiProjects, with each tier being characterized by a particular internal structure, role, and interaction with its peers and the community as a whole.

Tier 0

These projects (e.g. History, Culture, etc.) sit at the top of the subject-area hierarchies, and are so broad in scope that the WikiProject model is not useful to them. They will be kept as directories of their sub-projects and as (potential) common discussion areas, but they will not adopt any of the normal WikiProject collaborative processes. (In particular, they will not engage in article tagging except in cases where no more suitable descendant project's tag is available. If there is a desire for assessment statistics for these areas, their child projects will provide the necessary technical functionality to generate them through their own systems.)

Tier 1

These projects will engage in both WikiProject functions. In particular, they will be expected to operate the appropriate collaborative processes (e.g. peer review, article assessment, and so forth), and to provide support for Tier 2 projects wishing to make use of these processes. They will be the primary type of WikiProject that will maintain and place banner tags on article talk pages, and the only type to do so without limitations.

Tier 2

These projects will avoid the second WikiProject function in favor of using a parent Tier 1 project's processes. In particular, they will use the parent project's tags (which will be provided with the appropriate parameters) for their tagging and assessment work rather than creating their own.

Under this model, the traditional "task force" is essentially a Tier 2 WikiProject that happens to be located on a subpage of its parent project rather than on a completely separate page. The practice may or may not be a good idea, depending on the situation; but, in any case, it is envisioned that task forces and non-task force Tier 2 projects will be otherwise equivalent in terms of their role and function.

Tier selection

The question of which specific projects would fall into which tiers is open to further discussion; several approaches are presented below, and some combination of them may be the most workable solution.

Clustering

One obvious approach to placing projects into tiers is the idea of creating "clusters" of projects that heavily overlap in either scope or membership, and can thus be expected to work more effectively as a set of Tier 2 projects with a single Tier 1 project than they would otherwise. In particular, three different aspects might be considered:

Unparented groups

A project's ability to function as a Tier 2 WikiProject is dependent on the presence of a parent Tier 1 WikiProject that can provide the necessary process infrastructure for it. The obvious consequence of this is that a project with no active parent projects (where "parent" is used specifically to mean a broader project that entirely subsumes its scope, rather than any related higher-level project) will need to be placed at Tier 1 in order to avoid losing functionality.

Explicit national sub-groups

Projects oriented around particular countries and aspects of those countries tend to be both cleanly hierarchical and prone to the problems outlined above. As a consequence, it would be reasonable to declare that all country projects will be Tier 1 by default, and that subsidiary projects whose scope is "Something of somecountry" should be Tier 2 projects under the relevant country WikiProject. For example, WikiProject History of India would be a Tier 2 project under the Tier 1 India WikiProject.

Sub-groups by type of article

Groups of related projects whose scope is distinguished by the "type" of article they cover rather than by the overall topic area are very prone to overlap issues; in general, they should be Tier 2 projects under the Tier 1 project for the topic area. For example, the Songs and Albums WikiProjects would be Tier 2 projects under a Tier 1 Music WikiProject.

(In all cases, the Tier 2 projects involved may wish to become full task forces; but, as this entails no functional difference, but only a question of page locations, the issue will be left up to their own discretion.)

Accreditation

Another, likely secondary, approach would be a system of "accreditation" for WikiProjects, wherein projects would be reviewed by the community as a whole and would be assigned a status based on community consensus. While such a general system could be used for a variety of potential issues, the practical interest here would be in having the community determine whether a project was sufficiently well-scoped to be effective as a Tier 1 project, or whether it would work better as a Tier 2 project under some existing parent Tier 1 project.

The exact method by which such community discussion could take place is open to discussion.

Tagging

The above proposals would be expected to substantially reduce the number of project banners appearing on talk pages, most obviously through the elimination of hierarchical arrangements of banners.

However, this would not entirely eliminate the problem; there would still be an (albeit reduced) potential for an article to be tagged with a number of independent banners. In view of this, it is proposed that {{WikiProjectBanners}} (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.