Wikipedia:WikiProject Council/Guide/WikiProject

From Wikipedia, the free encyclopedia

Have you read the parent page, Wikipedia:WikiProject Council/Guide? If not, please read that first before reading any of this.

WikiProject Council

General information
Main page	talk
To-do list
Templates
Contacts	talk
WikiProject guide
Introduction	talk
WikiProjects
Task forces
Technical notes
Resources
Assessment FAQ
Directory	talk
Proposals	talk
Newsletters	talk
WikiProjects Portal
edit · changes

[edit] Initial setup

Once you have determined that you will create a new WikiProject (see the Guide for possibly better alternatives), you must create a base page for it. The naming convention for WikiProjects is to place them in the Wikipedia: namespace 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]]

Another possibility is to use {{WikiProject}}, by creating a new page with {{subst:WikiProject|Name of project}}; this produces a somewhat more complex layout. Finally, a third approach is to find an already active WikiProject—ideally one with a similar scope to the new project—and copy the structure of its project page directly. This method may require substantial trimming of unneeded sections, however, particularly where a very large project is used as a model; the largest projects often develop many complex structural features that would be excessively convoluted for a smaller one.

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!

[edit] 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 (you are strongly encouraged to use Template:WikiProject Project, so Template:WikiProject Tulips in this example. You can easily create redirects from easier-to-type titles like Template:WPTulips, etc) and create it with some simple contents:

{| class="{{#ifeq:{{{nested|}}}|yes|collapsible collapsed messagebox nested-talk|{{#ifeq:{{{small|}}}|yes|messagebox small-talk|messagebox standard-talk}}}}"
|-
{{#ifeq:{{{nested|}}}|yes|
! colspan="3" style="text-align: center" {{!}} [[Wikipedia:WikiProject Tulips|WikiProject Tulips]]
|-
|}
| [[Image:Tulip-blossom.jpg|45px]]
| 
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.
|}<noinclude>
[[Category:WikiProject banners|Tulips]]  
</noinclude>

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.

Alternatively, {{WPBannerMeta}}, the meta-template for WikiProject banners, can be used, which allows for easy expansion of the banner to add functionality as your project grows. At its simplest, the code:

{{WPBannerMeta
|PROJECT             = Tulips
 |BANNER_NAME        = {{subst:FULLPAGENAME}}
 |small={{{small|}}}
 |nested={{{nested|}}}
 |category={{{category|μ}}}
|IMAGE_LEFT          = Tulip-blossom.jpg
|MAIN_TEXT           = 
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.
}}<noinclude>
{{subst check|{{subst:FULLPAGENAME}}}}
</noinclude>

Produces:

Because the banner can be applied to a very large number of article talk pages, try to use an image that will look good at small resolutions to avoid overwhelming the page with the banner; an image size of 45px or 50px is the most common convention. This image must be free content—fair use images are not permitted.

The banner should be 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 (see WP:BOTREQ).

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.

Wikipedia:WikiProject Musical Instruments used the strategy of having, in addition to the Participants list, a Guestbook, which allows people who are sympathetic but time-limited to add their name. This seems to have attracted a number of people who are willing to help in a variety of ways, but might not have signed up as a participant.

[edit] 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.

[edit] 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); 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.

[edit] Assessment

Quality
FA
A
GA
B
Start
Stub

Quality
FL
List
Redirect
Disambig
Needed
Template
Category
Image
Portal
NA

For a more basic overview of article assessment, please see the Assessment FAQ.

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 left). A number of other classes have become de-facto additions to the 1.0 assessment scale, covering lists, redirects, portals, disambiguation pages and more. The full list of these additional classes is shown to the 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 (this is conventionally at Wikipedia:WikiProject Project/Assessment, although there is no hard-and-fast rule); 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.

[edit] 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 table, can to be replaced by a substitution call to the {{class parameter}} template:

{| class="{{#ifeq:{{{nested|}}}|yes|collapsible collapsed messagebox nested-talk|{{#ifeq:{{{small|}}}|yes|messagebox small-talk|messagebox standard-talk}}}}"
|-
{{#ifeq:{{{nested|}}}|yes|
! colspan="3" style="text-align: center" {{!}} [[Wikipedia:WikiProject Tulips|WikiProject Tulips]]
|-
|}
| [[Image:Tulip-blossom.jpg|45px]]
| 
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}}<noinclude>
[[Category:WikiProject banners|Tulips]]  
</noinclude>

Alternatively, the addition of a few extra lines to a banner using {{WPBannerMeta}} will have the same effect; adding the code:

|QUALITY_SCALE       = yes
 |class={{{class|}}}
|FULL_QUALITY_SCALE  =

to the banner example above will produce the banner:

	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.
FA	This article has been rated as FA-class on the quality scale.

Either option will produce template code which allows the project banner 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 ("FA" class in this example)
Place the talk page into a category corresponding to the rating (in this example, it would be Category:FA-Class Tulip articles

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.

[edit] "Importance"

Importance
Top
High
Mid
Low
NA

Some projects also make importance assessments. It should be noted, however, that these tend to be more controversial (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 and use the term "priority" to decrease perception problems.

If a project is to engage in assessments of importance, it may well be a good idea to make them a community decision. For example, the Biography and Novels projects have started processes in which the various members collaboratively determine the comparative importance of a given article to the project, and then use those final results as a guideline in determining which articles are most deserving of the project's attention in the short term.

Importance ratings are usually integrated into the WikiProject banner in the same fashion as quality assessments described above. Adding the code

|IMPORTANCE_SCALE    = yes
 |importance={{{importance|}}}

to a banner using {{WPBannerMeta}} will enable the importance scale for that banner, producing something like:

	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.
FA	This article has been rated as FA-class on the quality scale.
Top	This article has been rated as Top-importance on the importance scale.

In order for the importance assessments to be recognised by the assessment bot, you will need to create a category like Category:Project articles by importance and a number of subcategories. If you are an administrator, you can use an automated script found here to automatically create all the necessary categories for both the importance and quality scales for any particular project. Just make sure to replace "Foobar" by the exact name of your project (in this case, "Tulips", with an uppercase "T"), and to reset the tool when you're done.

[edit] Assessments in practice

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

In general, projects first engaging in assessments will face one problem almost immediately: getting the articles which fall within the scope of the project assessed. There are a number of automated tools available to assist in assessing the stub articles that fall within a project's scope, but project members will still need to go over the assessed stubs to ensure that they are assessed correctly. Often, it is the case that an article will have been expanded beyond stub level, or been incorrectly classified as a stub in the beginning, resulting in the tools incorrectly assessing the article.

Because of the potential importance of assessments to the success of the project, it is vital for the project to get as many members as possible interested in performing assessments. Clearly, it helps the project to have a member already familiar with the system (most often through another project), and for that member to step forward to assist in the initial assessments. Beyond that, it's helpful if, as one of the early tasks of the new project, members go through the articles of the project and assess those whose status they are sure of, while simply adding the banner to those articles about which they are unsure; then, when all the less-controversial assessments are done, the members of the project can focus on assessing the remaining less easily-definable articles.

Article assessment is not an exact science, and there will be a number of judgment calls made by the assessor when an article is on the borderline between two classes. At times like these, it is perfectly proper to request a separate assessment by a different editor, or if the article was previously assessed, to file a reconsideration of the first assessment. Because of this, there should be a place within the WikiProject—generally on the main assessment page—where editors can file requests for re-assessment. In addition, a number of WikiProjects have adopted more formal methods, such as formal group reviews or more explicit criteria, for assigning at least some of the assessment levels; other levels may be based entirely on external validation processes, such as peer review, good article candidacy, and featured article candidacy.

Graph of high-quality articles in the scope of Wikipedia:WikiProject Tropical Cyclones, demonstrating how the number of high-quality articles has increased since assessments began.

Once assessments have been started, and a WikiProject has assessed a large enough number of articles within its scope, the assessments can become very valuable, both to advance the encyclopedic purpose of the project, as well as to ensure comparatively high morale by fostering a sense of accomplishment of the members of the project. Generally, a given project will focus the majority of its attention in bringing up the articles of greatest priority to the project to a high standard of quality. As a result, its members usually remain with the project if they see that they are really accomplishing something via the project, by increasing the quality of these most important articles.

[edit] Peer review

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

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 constructive commentary on an article, and are particularly helpful for articles which are headed towards featured article candidacies. Project peer reviews are usually 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). A {{WPBannerMeta}} banner can easily add this functionality by adding the lines:

|PEER_REVIEW        = 
 |peer review={{{**PARAMETER**|}}}
 |old peer review={{{**PARAMETER**|}}}

There is, unfortunately, no easy way to add the functionality to a non-WPBannerMeta banner - you will need to copy the code from another non-WPBannerMeta banner like {{WPBiography}}. Once this functionality has been installed, editors will request a peer review by following a three-step process:

Add the appropriate parameter to the article's project banner.
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.
Add a transclusion of the newly created subpage to the list of requests on the main peer review page.

Functionality exists to automatically copy such WikiProject peer review requests to the central peer review listing; to enable it, add {{WikiProject peer review}} to the WikiProject 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, and provides a ready indication of the level of feedback a request has received.