Wikipedia:WikiProject Council/Guide

From Wikipedia, the free encyclopedia

This page is considered a guideline on Wikipedia. It is generally accepted among editors and is considered a standard that all users should follow. However, it is not set in stone and should be treated with common sense and the occasional exception. When editing this page, please ensure that your revision reflects consensus. When in doubt, discuss first on the talk page.

Shortcut: WP:PROJGUIDE

WikiProject Council
General information Main page talk    To-do list    Templates Contacts talk Resources Guide talk Assessment FAQ Directory talk Proposals talk Newsletters talk edit · changes

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 used.

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.

Contents 1 What is a WikiProject? 1.1 Task forces 2 Starting up 2.1 Before you Begin 2.1.1 Parent identification 2.1.2 Identify the best size 2.1.3 Identify format 2.1.4 Check for other proposals 2.2 Initial setup 2.3 Recruiting 3 Getting to work 3.1 Task lists 3.2 Assessment 3.2.1 Bot-assisted assessment 3.2.2 "Importance" 3.2.3 Assessments in practice 3.3 Peer review 3.4 Collaboration 3.4.1 Setting up the page 3.4.2 Selecting candidates 3.4.3 Maintenance and advertising 3.5 Developing guidelines 4 Auxiliary features 4.1 Member communication 4.1.1 Newsletters 4.1.2 Welcoming templates 4.1.3 User banners and boxes 4.2 Recognition and awards 5 Inter-WikiProject relations 5.1 Article tagging 5.2 Inter-project collaboration 5.3 Role of the WikiProject Council 6 Common pitfalls 6.1 Trying to do too much too quickly 6.2 Having an overly narrow scope 6.3 Not recruiting enough members 6.4 Depending too much on a few members 6.5 Getting into fights 6.6 Violating policies 6.7 Over-tagging 7 Technical notes 8 Project categories

[edit] What is a WikiProject?

The official definition of a WikiProject focuses on its function within Wikipedia:

A WikiProject is a collection of pages devoted to the management of a specific topic or family of topics within Wikipedia; and, simultaneously, a group of editors that use said pages to collaborate on encyclopedic work. It is not a place to write encyclopedia articles directly, but a resource to help coordinate and organize article writing.

A WikiProject, in other words, is a central place for editor collaboration on a particular topic area. It may develop guidelines, maintain various collaborative processes, keep track of work that needs to be done, and act as a forum where issues of interest to the editors of a subject may be discussed.

But what makes a WikiProject "work"? It is tempting, given the above definition, to view a WikiProject primarily as the sum of its article-related activities; in other words, to consider it merely an umbrella for some "pages devoted to the management of a specific topic or family of topics". Experience suggests, however, that a WikiProject must be more than a collection of processes and guidelines to succeed. What distinguishes a successful WikiProject is not the function of calling it a "WikiProject"; rather, it is that a WikiProject functions more as a grouping of editors than of articles.

A WikiProject is fundamentally a social construct; its success depends on its ability to function as a cohesive group of editors working towards a common goal. Much of the work that members must do to sustain a successful WikiProject—quality assessment and peer review in particular, but almost anything beyond the actual writing of articles—is tedious, often unrewarding, and usually unappreciated. To be effective, a WikiProject must 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—can a WikiProject muster the energy and direction to produce excellent articles systematically rather than incidentally.

[edit] Task forces

Shortcut: WP:TASKFORCE

A task force is, essentially, a non-independent subgroup of a larger WikiProject that covers some defined part of the WikiProject's scope. For example, the United States military history task force of the Military history WikiProject deals with the military history of a specific country; and the RuneScape task force of the Massively multiplayer online games WikiProject covers a single game.

The major distinction between a task force and a fully independent child WikiProject—and, indeed, the reason why the task force model was developed—is that the task force minimizes the bureaucratic overhead of its activities by relying on the parent project to provide as much of the procedural and technical infrastructure as possible. Thus, for example, a task force will use the core project's peer review and assessment processes rather than creating its own. This allows the task force to focus primarily on direct article-writing activity, without the need to devote extensive resources to maintaining its own internal structure.

A task force is generally set up on a subpage of the parent project page. In cases where the task force is a child of two projects (in other words, where its scope is the intersection of that of its two parents), the subpage can be arbitrarily placed under either of the projects, and a redirect can be created from the equivalent subpage in the other; see, for example, the Korean military history task force, run jointly by the Military history and Korea WikiProjects. The task force page can take any form, but should be initially constructed with minimal bureaucratic fluff. Projects with large numbers of task forces will often adopt a more-or-less standard layout for all of them, perhaps including common technical features; for example, each of the task forces of the Military history WikiProject has a standardized template for listing open tasks.

Task forces will generally not have their own talk page banners; instead, they are integrated directly into the parent project's banner via an optional parameter. For example, {{WPMILHIST}} includes a large number of task force parameters. It is possible to use this integration to automatically generate assessment data for a task force based on the assessments entered for the main project; this ensures that task forces don't need to conduct assessments independently.

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

[edit] Before you Begin

[edit] Parent identification

Before you even begin, you should identify your project's immediate parents, as they may be able to help you in setting up your project. The suggested methods (all of which should be used) are:

• Examine the WikiProject Directory and see if you can identify any projects which might be parents for yours. For the example of the proposed WikiProject Tulips, you might be looking up WikiProject Netherlands in the Geographic section of the directory, and WikiProject Horticulture and Gardening from the Science section.
• Examine the Portal Directory likewise looking for parents

Inactive parents are irrelevant here, and can safely be ignored.

[edit] Identify the best size

Next, identify the best size for your project. For example, are Tulips too small a project scope, such that it might only ever have a few dozen articles and ten project members (some of whom don't do much)? Either of those criteria should be enough to make you think that maybe a larger scope would be better. You might be able to get a more reasonable sized project by including the entire Lily family, which includes tulips.

In simple form, the risks of a narrow scope are:

• Not enough people (your project may die from administrative overload, and become one of the 192 Inactive WikiProjects)
• Not enough pages (your project may die from administrative overload, and likewise become inactive)

To estimate the number of pages, go to the main article, look at "What links here", and that's probably your number, unless you limit the scope in some way (ie. only including significant Tulip growers (not fanciers) from before 1900 in the Biography category).

The simplest way to achieve all this is to ask yourself what difference it would make if you had a more inclusive project.

Having considered all this, you also have to ask yourself "Is this a 'natural' scope?". Certain scopes are structured such that subsets of those scopes intersect heavily in their editor base; for example, projects on each species of tulip would nearly all be attracting the same editors: the tulip-lovers (who tend to be interested in tulips as a whole, rather than on a per-species basis). Having separate projects here is thus counterproductive; you wind up with multiple projects that have the same membership.

[edit] Identify format

Having identified the size you want for your project, the next thing to consider is the best format for the project. The current suggested formats are:

• Inter-WikiProject co-ordination: if your scope was too large, but you're still keen, you'll probably want, instead, to identify potential child WikiProjects, and try to help them co-ordinate; this doesn't require a WikiProject in itself. Talk to the potential child WikiProjects about co-ordination, and see what sort of response you get. Be careful not to try to dictate to them; they could be sensitive about you appearing out of nowhere and wanting to assimilate them. If this is the format you choose, the rest of this document, while good background reading, is not essential (although it may help you not to look like an idiot).
• A full-blown WikiProject: If your scope appears to be at the right level for a WikiProject, continue with the document below.
• A task force: If your scope appears to be too small, maybe a task force is the right approach. A task force uses most of the administrative structure of their parent project, but works together as a smaller group. The best way to start a task force is to join the parent WikiProject(s), and ask if they can help you form a task force.
• Just a little bit of collaboration: if even a task force is overload. This might include posting a note on the Tulips page, saying that you want to try to get at least a Start-class article on each of the different species of Tulip, and listing all the articles with links, and encouraging people to put their name next to one that they're volunteering for. Or any other Talk-page based collaboration you can think of

One of the best ways to determine which format to use is to look at the "parent" WikiProject(s) and see what other children they have. 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.

[edit] Check for other proposals

This is pretty simple: Go to WikiProject Proposals, and see if anyone else is already proposing this.

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

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.

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.

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.

[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

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

[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="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.

[edit] "Importance"

Importance

Top

High

Mid

Low

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.

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

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). 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.

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.

[edit] Collaboration

[edit] Setting up the page

[edit] Selecting candidates

[edit] Maintenance and advertising

[edit] Developing guidelines

A good example of some guidelines is Wikipedia:WikiProject_Guitarists#Guidelines. You may also be interested in Wikipedia:WikiProject Biography's Structure section, as well as their guidelines.

[edit] Auxiliary features

[edit] Member communication

With luck, any project will expand over time, as the number of articles and contributors expand. Growth can itself be a problem, however, as the greater number of members and articles reduces the likelihood for individual group members to have contact with each other, and could potentially lead to factions within a project. For this reason, and others, projects are encouraged to develop a variety of regular communications. These might include newsletters, meetups, active conversation between members working in the same area of the project, and the like. Collaborations can also serve as an effective way to try to bring unity to the members, if they are successful.

One way of getting news to everyone is to put all the news on one page, and then ask people to either include the page on their own user page, or add it to their watchlist.

[edit] Newsletters

[edit] Welcoming templates

[edit] User banners and boxes

[edit] Recognition and awards

[edit] Inter-WikiProject relations

[edit] Article tagging

Many articles will be tagged by more than one WikiProject. This is particularly true of articles which deal with prominent people, as those articles may be tagged by WikiProjects for biography, their places of residence, their professional field, and any other activities they may engage in. This can and occasionally does create problems, as some projects will, quite reasonably, think that another project might be only minimally capable of assisting in the improvement of an article. However, it is important for all parties to remember that beyond simply being WikiProjects, they are also collections of people with specific abilities and competencies which might not be available within other groups. A member of a football project might be better able to copyedit an article about a player from a non-English speaking country, who might even go on to achieve prominence elsewhere and draw the attention of other projects, than a native speaker of that country who might be less skilled at English composition. On that basis, it is a good idea to welcome any banner placements on an article provided that the banner is actually at all relevant to the subject. The fact that these other projects may also regularly "check up" on the article for improvements, vandalism, etc., can also be beneficial. However, there may well be times when someone clearly places the wrong banner on an article. When this happens, it is generally a good idea to approach either that individual or that project to determine why the banner was placed. Doing so reduces the likelihood of inter-project animosity, and also could potentially help the article in some way. Examples might include instances when a project's scope has expanded in some way to include the article, which, if true, might help in the development of the article. Also, there is the possibility of an article being miscategorized, which might not draw the attention of your own project otherwise. In instances like these, like in all others, civility, respect for others, and clear and unambiguous communications are to be greatly valued.

[edit] Inter-project collaboration

There may also arise situations in which it is beneficial for an article to be actively collaborated upon by multiple projects. A short article about a prominent scientist, for example, would probably benefit greatly from a project dealing with the scientist's discipline, his area of residence, biographies in general, and potentially even his time period. In instances like this, it may be a good idea to propose the article for the Wikipedia:Article Improvement Drive, and inform all of the relevant projects of the nomination. By so doing, it is more likely that the members of the individual projects will interact beneficially, which could improve their mutual opinions of each other and likelihood of further interaction. Also, clearly, having high-quality content inserted from all relevant sides cannot be bad for the development of the article. Even if not nominated for the Improvement Drive, it is always beneficial to contact other projects, and inform them about your project's desire to expand the article. That way, other projects can provide copyediting for grammar and conventions, reference materials, or general advice about how to improve the article.

[edit] Role of the WikiProject Council

There may still arise situations when there is a seemingly intractable disagreement between projects. When that happens, it might be the case that perhaps the WikiProject Council might be able to step in and help arbitrate the matter. This group contains people who have generally shown some ability at working with and in groups, and may be able to be of assistance. It should however be noted that no group is or should be obligated to follow its comments or recommendations, except in those instances when specific formal actions are in fact taken which might involve the Council in some way. In severe cases, using formal dispute resolution channels may be an appropriate action; however, those cases should occur in the rarest of events, when no other plausible resource to solve the disagreement is feasible or available.

[edit] Common pitfalls

[edit] Trying to do too much too quickly

[edit] Having an overly narrow scope

[edit] Not recruiting enough members

[edit] Depending too much on a few members

[edit] Getting into fights

[edit] Violating policies

[edit] Over-tagging

[edit] Technical notes

There's lots of useful information about creating different templates at Wikipedia:WikiProject Council/Guide/Technical notes. That page discusses:

• Advanced project banners
• Internal navigation templates
• Task list templates (eg. {{todo}} and custom versions thereof

Some of these also include information about Task Forces

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

• A top-level category for the project; it should have the same name as the project itself—in this case Category:WikiProject Tulips. The category should be placed under one of Category:WikiProjects's subcategories (e.g. Category:Science WikiProjects) instead of under Category:WikiProjects directly. If there is a "parent" WikiProject with a category (e.g. Category:WikiProject Flowers), the new category should be made a subcategory of that as well. It is generally not a good idea to place articles directly into this category; for all but the smallest projects, they will quickly overwhelm the internal pages, making them quite difficult to locate.
• Once the project begins to develop article-related processes, such as assessment or peer review, it is appropriate to create a subcategory for the various articles being tagged into them; the conventional name for this is formed by appending "articles" to the project name (e.g. Category:WikiProject Tulips articles). This can have a number of different subcategories:
  • Article assessment requires a Category:Tulips articles by quality (and, optionally, a Category:Tulips articles by importance), which must also be a subcategory of Category:Wikipedia 1.0 assessments. These will have further subcategories that follow the levels of the assessment scales, such as Category:A-Class tulips articles and Category:B-Class tulips articles for quality assessments.
  • Peer reviews and collaborations will usually require pairs of categories for current and archived articles (e.g. Category:Requests for tulips peer review and Category:Old requests for tulips peer review).
  • Task forces usually have at least one category for each task force; for an example of this, see Category:Military history articles by task force.
  • The articles category might have other subcategories containing such things as stubs, merged articles, articles needing attention, and so forth; an example of this type of management can be seen at Category:WikiProject The Beatles articles.
• Many projects also create a category for the project's members; this would generally be named either Category:WikiProject Tulips participants or Category:WikiProject Tulips members. The category should be a subcategory of Category:Wikipedians by WikiProject, and may sometimes be be populated through a userbox.
• The largest WikiProjects will often acquire a number of other categories for organizing things such as templates or archives.

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.