Jump to content

Wikipedia:WikiProject Council/Guide

From Wikipedia, the free encyclopedia
< Wikipedia:WikiProject Council

This is an old revision of this page, as edited by Kirill Lokshin (talk | contribs) at 21:59, 22 August 2006 (→‎Recruiting: Note). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

This page aims to be comprehensive guide to organizing and running a WikiProject. It should be noted, however, that it necessarily restricts itself to the more common and well-understood aspects of WikiProjects. Individual projects will often develop more unusual features that depend on peculiarities of the projects' scope or activities; the best way to discover these is to observe what successful WikiProjects are doing, as it is unlikely that this guide will ever include every possible idea that a project may have made use of.

The guide is primarily concerned with topical WikiProjects—that is, WikiProjects whose goal is the improvement of articles within a certain subject area. Maintenance WikiProjects, such as stub-sorting, disambiguation, or other cleanup tasks, have a distinctly different structure and organization of activity, so much of the advice given here may not apply to them.

What is a WikiProject?

What is a WikiProject, really? It is tempting to view a WikiProject as no more than the sum of its article-related activities; in other words, to consider it merely an umbrella for certain processes related to encyclopedic improvement. Experience suggests, however, that even the best-designed processes will not function in isolation; and that a WikiProject must be more than a collection of processes and guidelines to succeed. What distinguishes a WikiProject is not the function of calling it a "WikiProject"; rather, it is that a WikiProject functions as a grouping of editors moreso than of articles.

A WikiProject is fundamentally a social construct; its success depends entirely on its ability to function as a cohesive group of editors working towards a common goal. Much of the work that is done by a "successful" WikiProjects—quality assessment and peer review, in particular, but this applies equally well to almost anything beyond individual members' article-writing—is tedious, often unrewarding, and usually unappreciated. Inertia is usually insufficient to keep the project going; a successful WikiProject must take active steps to foster not only interest in the topic of the project, but also an esprit de corps among its members. Only where group cohesion can be maintained—where, in other words, project members are willing to share in the less exciting work because they wish to help one another—can a WikiProject muster the energy and direction to produce excellent articles in a systematic, rather than incidental, manner.

Starting up

The advice presented in this section is intended primarily for projects that are just starting up—or are being brought back to activity—as well as for editors who may be considering creating a new WikiProject; however, anyone involved with WikiProjects might find some items of interest.

Is a project needed?

The first question that must be asked when someone has an idea for a new WikiProject is: "Is a separate WikiProject the best approach?" The answer depends on two very distinct factors.

First, is the topic broad enough that the extra administrative overhead is worth it? Obviously, we could create separate projects for every article should we wish to; but, just as obviously, we don't, as it would be much easier to simply collaborate on the talk page. In general, if there are less than a few dozen articles within the projected scope of the project, it would probably be more efficient to simply work within a larger project which includes them. Similarly, the number of potential members should be considered; if you are the only editor working in a particular area, creating a project probably isn't worth it.

Second, if the topic is broad enough that some manner of formal organization is worthwhile, is an independent WikiProject the best answer? The best way to determine this is usually to look at other projects on similar topics, and at the "parent" WikiProject for the broader topic. In some cases, each similar topic is handled by a separate WikiProject; if this is the case, then creating a new one is a good idea.

In other cases, however, the projects are not separate, but are instead task forces of the central WikiProject for the area; in this case, approaching the central project—which typically has a more developed framework for dealing with sub-groups—with the idea is usually the more effective approach. (This applies equally to inactive projects being brought back to activity; the "parent" project will often be willing to adopt the inactive project as a new task force, in which case its members can offer considerable assistance in getting it running.) If this is the case, reading the rest of this guide is probably not required; the larger central project will help you integrate with the specific setup it has.

Initial setup

Once you have determined that you will create a new WikiProject, you must create a base page for it. The naming convention for WikiProjects is to place them in the Wikipedia: space at "WikiProject Name of project" (note that the "WikiProject" prefix is considered to be a virtual namespace; thus, the first word after it is capitalized, but any others follow standard sentence case rules); for example, if you were creating a WikiProject about tulips, you would create the page at Wikipedia:WikiProject Tulips.

One possible outline for a new WikiProject page is given here; wording appropriate to the topic should be substituted as required: 

Welcome to the Tulips WikiProject!

; Goals
* Improve Wikipedia's coverage of tulips.
* Create guidelines for articles about tulips.

; Scope
* The project covers all articles about tulips and their cultivation and use.

== Members ==
# {{User|MyName}} (interested in everything about tulips)

== Open tasks ==
* ...

== Categories ==
* [[:Category:Tulips]]
* ...

== Templates ==
* ...

== Related projects ==
* [[Wikipedia:WikiProject Flowers]]

[[Category:WikiProjects|Tulips]]

In general, a new WikiProject page should be kept as simple as possible, and should be permitted to grow organically. While it may be tempting to create a page with dozens of rarely used sections of boilerplate, this is usually a bad idea; a small project usually cannot focus on many areas at once, and an excessively complex structure can discourage potential new members—particularly if they're joining their first WikiProject!

Recruiting

One of the most basic aspects of keeping a WikiProject active is recruiting editors. A WikiProject must recruit new members to make up for attrition; any project that fails to do this will eventually collapse.

How, then, to recruit these precious participants? By far the most effective method is through the use of a project banner template. The more sophisticated forms of these include a variety of additional features to cope with the needs of larger projects; but, for a project that's just starting off, a simple banner may be sufficient. Supposing, again, that you had started a "WikiProject Tulips", you would choose a suitable template name (an obvious one would be Template:WikiProject Tulips, but other variations are possible) and create it with some simple contents: 

{| class="messagebox standard-talk"
|-
| [[Image:Tulip-blossom.jpg|50px]]
| 
This article is within the scope of the '''[[Wikipedia:WikiProject Tulips|Tulips WikiProject]]''', 
a collaborative effort to improve Wikipedia's coverage of tulips.  If you would like to participate, 
you can visit the project page, where you can join the project and see a list of open tasks.
|}

Which produces:

This article is within the scope of the Tulips WikiProject, a collaborative effort to improve Wikipedia's coverage of tulips. If you would like to participate, you can visit the project page, where you can join the project and see a list of open tasks.

This banner should be liberally added to the talk page of any article within the project's scope; if the scope happens to be well-defined by another factor—a category, for example, or a stub type—there are a number of bots which may be able to assist in placing it.

Another effective way to recruit members is through direct invitation. If there are other editors who are highly active in working on the project's topic, they should be identifiable by looking at the histories and talk pages of the articles; leaving them polite messages asking them to take a look at the newly active project will often produce an influx of new members. In practice, however, this method cannot match the performance of talk page banners in bringing in large numbers of new members, and is more suited towards attracting editors of particular interest, such as subject-matter experts, to the project.

Getting to work

Once a project has begun to attract members, the pressing problem becomes finding something for them to do. Keeping people around is harder than recruiting them; bored editors will quickly leave.

Task lists

The most common—and simplest—approach to focusing the attention of project members on particular articles is the creation of a central list of open tasks. For smaller projects, this will often take the form of a simple section on the project page (sometimes using the {{todo}} template, although this creates additional subpages which may not be needed); larger projects will usually create a special template (which may be arbitrarily complex).

There are a number of different items which are usually included on project task lists:

Announcements
General announcements of important discussions and major tasks being undertaken. This may not be necessary for a small project—where such points can be better raised on the project's talk page—but becomes more important as the project grows and the traffic on the discussion page increases.
FACs and FARs
One of the most important items to announce to the project; particularly for a younger and smaller project, a successful FAC can be a great morale booster—but will often require the assistance of multiple project members to succeed.
Peer reviews
Requests for peer reviews; these can be project-specific peer reviews, if the project has adopted such a process, or selected entries from the main peer review page if it has not.
Requested articles
Articles which do not yet exist, but which should be created. These can often be culled from existing lists or navigational templates related to the project's scope.
Cleanup and expansion requests
These can be added manually, or collected from existing cleanup categories.

Unlike the first three categories—the size of which is generally limited—the last two can grow very quickly. It is usual, in this case, to create "overflow" lists from which entries may be rotated onto the main list as needed, and to limit the central lists to a dozen or two entries of each type. For example, a complete list of articles which need to be created may be collected on a subpage (such as Wikipedia:WikiProject Trains/Todo/Write or Wikipedia:WikiProject Military history/Article requests); this list may grow to include hundreds of entries, which would be impossible to place in a reasonably-sized template. In this case, a selection of entries from this list—as well as a link to the list itself—is placed on the project's task list, to avoid overwhelming viewers.

Assessment

Quality
FA
A
GA
B
Start
Stub

One of the most common methods used by WikiProjects to monitor and prioritize their work is that of assessing the articles within their scope. The de facto standard for these assessments is the Version 1.0 Editorial Team's assessment scale (shown at right); some projects, such as The Beatles WikiProject, have added additional levels to account for more unusual circumstances.

A very small or less-active project can keep a hand-compiled table of assessments; as the number of articles increases, however, a specialized process becomes necessary. The first stage of this is the creation of a subpage (sometimes known as an "assessment department") for the assessment work; these can take a number of different forms, some more formal than others (see, for example, the Military history and Tropical cyclones pages). However, the essential limitation—that of the hand-compiled list—requires a more sophisticated approach: bot-assisted assessments.

Bot-assisted assessment

The bot-assisted assessment scheme works by embedding assessments in a WikiProject's talk page banner. Using the WikiProject Tulips example from above, the last line in the template's code, which closes the Wikitable, can to be replaced by a substitution call to the {{class parameter}} template: 

{| class="messagebox standard-talk"
|-
| [[Image:Tulip-blossom.jpg|50px]]
| 
This article is within the scope of the '''[[Wikipedia:WikiProject Tulips|Tulips WikiProject]]''', 
a collaborative effort to improve Wikipedia's coverage of tulips.  If you would like to participate, 
you can visit the project page, where you can join the project and see a list of open tasks.
{{subst:class parameter|category = Tulips}}

(Note that other approaches to constructing a proper template are possible; see the discussion below for more details.)

This will produce template code which allows the project template to take a "class" parameter (e.g. {{WikiProject Tulips|class=B}}) to indicate the assessment rating; inserting the parameter does two things:

  • Display the corresponding rating in the banner itself.
  • Place the talk page into a category corresponding to the rating.

The key to the process are these latter categories. A full description of their structure is given below; essentially, a bot monitors categories of a certain structure (such as Category:Military history articles by quality), and produces a comprehensive index of assessments for every participating project. This includes a worklist, overview statistics, and a log of changes.

"Importance"

Importance
Top
High
Mid
Low

Some projects also make importance assessments. It should be noted, however, that these tend to be more controverial (since calling articles "unimportant" can lead to conflicts); as a result, some projects (such as Military history) do not assess importance, while others (such as Biography) only undertake importance assessments for a limited set of articles.

Assessments in practice

See Category:WikiProject assessments for a full list of active assessment departments.

Peer review

Another very common process for a WikiProject to undertake is the peer review of articles. This is usually not a true peer review in the academic sense, but is instead a review by project members; such peer reviews are invaluable in obtaining consructive commentary on an article, and are particularly helpful for articles which are headed towards featured article candidacies. Project peer reviews are usully more helpful than Wikipedia-wide ones, both because there is a greater chance of encountering a reviewer with some knowledge of the topic, and because it is much easier for project members to notice new requests without the need to filter out the vast majority of ones not related to their area of interest.

For very small projects, an informal system of requesting reviews on the project's primary talk page may suffice; as a project grows, however, it is usually appropriate to create a dedicated page for the peer review process (such as the military history or biography ones). This page typically includes a brief section of instructions, followed by transcluded subpages for the individual reviews; these subpages are also linked from the project banners, where the presence of a link is controlled by a template parameter (often peer_review=yes). Editors will request a peer review by following a three-step process:

  1. Add the appropriate parameter to the article's project banner.
  2. Follow the displayed link to a new subpage—having the same name as the article—and add a link to the article (usually in a third-level header) along with any remarks or special requests.
  3. Add a transclusion of the newly created subpage to the list of requests on the main peer review page.

The amount of time an article will spend being reviewed will vary, both according to the initial condition of the article—articles which are judged to be ready for FAC may be quickly nominated there, ending the review—and the attention the request receives; for moderately active peer review pages, archiving older reviews after a few weeks is usually a good approach.

One useful convention which has been adopted by many WikiProjects' peer review departments is that of having reviewers create a sub-section with their name to use for their comments. This allows extensive commentary and back-and-forth discussion to take place without the need for complicated indentation tricks to keep multiple reviewers' comments identifiable.

See Category:WikiProject peer reviews for a full list of active WikiProject peer review departments.

Collaboration

Outreach

Handling growth

Developing guidelines

Task forces

Coordinators

Social dynamics

Common pitfalls

Technical notes

Advanced project banners

Internal navigation templates

This section discusses internal navigation templates for WIkiProjects; for navigational templates used in articles, see Wikipedia:Navigational templates.

As a WikiProject grows, it begins to acquire large numbers of subpages for various specialized purposes (such as assessment and peer review work or task forces); the largest projects can have dozens of subpages. The best way to ensure that all of these subpages can be easily located is to create a navigational template linking to them.

Most projects follow a fairly standard design for the template. It is placed as a right-floating bar, listing subpages (and usually corresponding talk pages), one per line. Here, for example, is part of the code for the navigational template used by the Lithuania WikiProject: 

{| cellpadding="0" cellspacing="0" style="float: right; clear: right; border: 1px solid #aaa; 
padding: 5px; margin: 0em 0em 1em 1em; max-width: 300px; background: white;" 
! style="background: #99FF66; padding:5px; text-align: center;" | 
[[Image:Lietuvos-Lithuania 5.png|left|50px]] 
[[Wikipedia:WikiProject Lithuania|Lithuania<br/> WikiProject]]
|- 
|
{| cellpadding="3" cellspacing="0" style="font-size: 90%; width: 100%; background: ivory;"
|- style="background: #CCFF99; "
! colspan="2" style="text-align: center; border-top: 1px solid black; " | 
General information
|- 
| [[Wikipedia:WikiProject Lithuania|Main project page]]
| [[Wikipedia talk:WikiProject Lithuania|talk]]
|- 
| [[Template:WikiProject Lithuania|Project banner]]
| [[Template talk:WikiProject Lithuania|talk]]
|-
| [[Wikipedia:WikiProject Lithuania/Tips|Top 10 tips]]
| [[Wikipedia talk:WikiProject Lithuania/Tips|talk]]
|-
| [[:Category:Extremely short Lithuania articles|Extremely short articles]]
| [[Category talk:Extremely short Lithuania articles|talk]]
|- 
! colspan="2" style="text-align: center; border-top: 1px solid black; background: #CCFF99; " | 
[[Wikipedia:WikiProject Lithuania/Assessment|Assessment]]
|- 
| [[Wikipedia:WikiProject Lithuania/Assessment/Summary|Summary]]
| [[Wikipedia talk:WikiProject Lithuania/Assessment/Summary|talk]]
|- 
| colspan="2" align="center" | 
{{Wikipedia:Version 1.0 Editorial Team/Lithuania articles by quality statistics}}
|}
|}

Note the inclusion of the project's article assessment statistics at the bottom of the template; for larger projects with many more subpages, adding these may unacceptably lengthen the template, but this works quite well for smaller projects.

Another common feature for on navigational templates can be seen at the bottom of the navigational template used by the Military history WikiProject: 

...
|-
| colspan="2" | 
<small class="editlink noprint plainlinksneverexpand">
[{{SERVER}}{{localurl:Template:WPMILHIST Navigation|action=edit}} edit] · 
[[Special:Recentchangeslinked/Template:WPMILHIST Navigation|changes]]
</small>

The key is the "changes" link; when the template is properly constructed, Special:Recentchangeslinked can be used to view, at a glance, any changes made to any of a WikiProject's pages.

The visual layout of project navigational templates tends to vary by project, with three stripe colors, two stripe colors, or colored boxes being common.

Task list templates

Project categories

As WikiProjects have become more common, the need for a standard system of categories for the projects' internal use has become apparent. WikiProjects usually expand their category namespace as they grow; but (using the example of WikiProject Tulips again) there are several possible categories that can be created:

Further examples of category trees in actual use can be found by browsing Category:WikiProjects; a few examples showing many of the features described above are Category:WikiProject The Beatles, Category:WikiProject Biography, and Category:WikiProject Military history.

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:WikiProject_Council/Guide&oldid=71254655"