 | This page is currently inactive and is retained for historical reference. For more and current informations on Wikipedia reforms please go to Wikipedia:Reforms. |
 |
This is an essay.
It contains the advice or opinions of one or more Wikipedia contributors. This page is not an encyclopedia article, nor is it one of Wikipedia's policies or guidelines, as it has not been thoroughly vetted by the community. Some essays represent widespread norms; others only represent minority viewpoints. |
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:
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
