Wikipedia:WikiProject reform
From Wikipedia, the free encyclopedia
 |
This is an essay; it contains the advice and/or opinions of one or more Wikipedia contributors. It is not a policy or guideline, and editors are not obliged to follow it. |
- Please edit this proposal!
Contents |
[edit] 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:
- WikiProjects function as centralized discussion areas for issues concerning their chosen scope; this includes things such as guideline development for articles under their purview.
- WikiProjects also function as centralized areas for collaborative processes, such as article quality assessment and peer review.
[edit] 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.
[edit] 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.
[edit] 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.
[edit] 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.
[edit] 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.
[edit] Reform proposals
[edit] 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.
[edit] 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.
[edit] Rebuttal
Too complicated, too forceful, likely to lead to bad feeling. See Wikipedia_talk:WikiProject_reform#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.
[edit] Process
- Templates are posted, notifying associated parties of the proposal, and discussion is solicited
- Consensus is reached before changes are made
