This page documents an English Wikipedia guideline. It is a generally accepted standard that editors should follow, though it should be treated with common sense, and occasional exceptions may apply. When editing this page, please ensure that your revision reflects consensus. When in doubt, discuss your idea on the talk page.

Shortcuts: WP:PROJGUIDE WP:COUNCIL/G

WikiProject Council
Main page talk WikiProject guide Introduction    WikiProjects    Task forces    Technical notes Directories WikiProjects Proposals Newsletters edit · changes

This page is about organizing and running a WikiProject. It should be noted, however, that coordinators of WikiProjects are not limited to these methods. Individual projects will often develop more unusual features that depend on peculiarities of the projects' scope or activities; the best ways to discover these is through innovative experimentation, or to observe what successful WikiProjects are doing. 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? 2 Before you begin 2.1 Check for existing proposals 2.2 Identify any parent projects 2.3 Identify the best scope 2.4 Identify the best structure 3 Topic coordination 3.1 Talk page information 3.2 Topic coordination on a talk page 4 Inter-WikiProject coordination 4.1 Article tagging 4.2 Inter-project collaboration 4.3 Role of the WikiProject Council

[edit] What is a WikiProject?

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

The pages of a WikiProject are the central place for editor collaboration on a particular topic area. Editors there may develop criteria, 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, or 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. When group cohesion is maintained—where, in other words, project members are willing to share in the less exciting work—a WikiProject can muster the energy and direction to produce excellent articles systematically rather than incidentally.

[edit] Before you begin

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] Check for existing proposals

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

[edit] Identify any parent projects

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.
• Check the talk pages of any key articles to see whether they have been tagged as being within the scope of any potential parent projects.
• If a closely related group is inactive, you should consider reviving it rather than starting yet another WikiProject.
• If your area fits neatly within an existing "parent" group, then consider becoming a focused task force. Task forces have all the benefits of regular projects, such as a dedicated talk page for article coordination, and fewer administrative hassles.
  • Because many inactive WikiProjects were started before the task-force structure was formalized, inactive groups with a limited topical scope should be turned into task forces of their "parent" WikiProject so as to lighten their administrative load.

[edit] Identify the best scope

Next, identify the best scope 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 reasonably 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 more than 350 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 (i.e. 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 the best structure

Having identified the scope you want for your project, the next thing to consider is the best structure for the project. The typical structures are:

Topic coordination

This format is appropriate if you want to co-ordinate across just a few pages. See the separate section below for details.

Task force

This format is appropriate if your scope is a little larger. 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. Note that most WikiProjects are happy to have someone who is keen to start a task force.

WikiProject

If your scope appears to be at the right level for a WikiProject, then read that document, but keep in mind that you'll still want to investigate the parent project because they may already have a task force covering the same topic.

Inter-WikiProject coordination

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

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] Topic coordination

If you just want to do a little bit of topic coordination (i.e. even a task force is overload) because you want to co-ordinate across just a few pages, you might find the ideas in the following sections useful.

[edit] Talk page information

Naturally, when co-ordinating work on the talk pages, you should follow the Talk page guidelines.

Having said that, it is often useful to alter the talk page to help focus on the improvements currently needed to that page (which may not be limited to your topic co-ordination, but may certainly include it). You may find the following links helpful in this:

• Wikipedia:Refactoring talk pages
• Wikipedia:How to archive a talk page

[edit] Topic coordination on a talk page

Here's one example of how to go about a topic coordination on a talk page. There are no doubt other ways; if you come across something else that works well for you, feel free to document it here. The example below uses Tulips.

1. Post a note on the Talk:Tulip page (this being the primary page for the tulips articles), saying:
   1. Your goal: that you want to try to get at least a Start-class article on each of the different species of Tulip
   2. Your to-do list: list all the articles as intra-wiki links, and encourage people to put their name next to one that they're volunteering for, or have done. You will also want to see Wikipedia:To-do list
2. Do a little networking; link from the other talk pages back to your section of the main one, using Template:Topic co-ordination link

[edit] Inter-WikiProject coordination

[edit] Article tagging

WikiProjects do not own articles

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. Placement of any relevant banner should generally be accepted, as each project may have unique resources and be willing to improve and monitor the article.

However, on occasion, someone clearly places the wrong banner on an article. When this happens, it is polite to ask either that individual or that project why the banner was placed. Doing so reduces the likelihood of inter-project animosity, and also could potentially help the article in some way. For example, a project's scope may have expanded to include the article; they might now be willing to work on the article. Also, particularly when a bot is being used to tag articles, the article may have been tagged because it is miscategorized. In instances like these, like in all others, civility, respect for others, and clear, unambiguous communications are to be greatly valued.

A specific community consensus is in place for which "WikiProject country" tag to use on an article about a city, especially if the city has changed hands several times over the course of history: if there is disagreement, then only the Wikiproject for the city's current country should tag the article. For example, though the Germans occupied France during World War II, it would not be appropriate to put articles about French cities under WP:WikiProject Germany. For more information, see the consensus discussion.

In some topic areas it may be the case that the choice of which WikiProject tags to place, could cause conflict. In such situations, the best solution may simply be to remove all WikiProject tags, rather than argue endlessly about which tag to use.

Article editors do not own WikiProjects

Many editors place banners on behalf of a WikiProject that they are not members of. This practice is normally welcomed by WikiProjects as it brings to their attention new and interesting articles.

Please be judicious in making such placements by minimizing the number of outside banners that you place on an article and by carefully reviewing the scope of the project. Information about the project's scope is often available on the WikiProject's main page, and sometimes also on documentation associated with the template. If you are uncertain that the placement will be welcomed, then leave a note on the project's talk page instead of placing the banner yourself.

If you place a banner for an outside WikiProject, and a member of that project removes it, do not replace the banner. A WikiProject's members have the exclusive right to define the scope of their project, which includes defining an article as being outside the scope of the project. Similarly, if a WikiProject says that an article is within their scope, then you may not force them to remove the banner.

Overtagging is disruptive

All editors should avoid tagging an article with a disruptive number of WikiProject banners. Banners take up a significant amount of space on the talk page; this can be minimized by enclosing all banners in a template such as {{WikiProjectBanners}}, a shell that is compressed and, as indicated on its documentation and on the Talk page layout project page, should be used when there are more than six project banners on the page or {{WikiProjectBannerShell}}, an uncompressed shell that is to be used when there are more than two and fewer than six banners on the page.

WikiProject banners should not be used to duplicate the category system or portals. If an article is only tangentially related to the scope of another WikiProject, then please do not place that project's banner on the article. For example, washing toys for babies reduces transmission of some diseases, but the banners for WP:WikiProject Health, WP:WikiProject Biology, WP:WikiProject Virus and/or WP:WikiProject Medicine do not need to be spammed to Talk:Toy.

For projects involved in the WP:1.0 assessment program, every banner placed is a demand for an assessment according to the project's guidelines. It is more friendly to omit outside WikiProjects that you think will rate the article as low importance relative to their specific field.

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