Wikipedia:WikiProject Council/Guide/WikiProject

This page is a detailed instruction set for creating a new WikiProject. For more general guidance on WikiProjects, see Wikipedia:WikiProject Council/Guide.

This page provides instructions and advice for setting up a new WikiProject and for utilizing the various resources that community members have developed for organizing WikiProjects' efforts.

Initial setup

Create a project page

After a successful project proposal, it's time to set up a new project! First, a project will need a base page. WikiProjects are generally in project namespace so you'll create your WikiProject home page at Wikipedia:WikiProject Your new project. The contents of the home page may vary but tend to include the project's scope, goals, participants, and some to-do list items. Most projects use the template {{WikiProject}} to fill their project page. This is done by substituting the template by adding the text {{subst:WikiProject|Name of project}} to your project page. Alternatively, you can copy the text from another project and adapt it accordingly.

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 participants—particularly if they're joining their first WikiProject!

Notify others

Now that your project exists, point other interested editors your way! Leave a short post on the talk pages of related projects to notify others of the new project's existence. List the project at the manually maintained Wikipedia:WikiProject Council/Directory (Instructions for the template it uses are here). The automatically maintained directory updates based on the WikiProject category tree, so add your project to one of the subcategories of Category:WikiProjects (e.g. Wikipedia:WikiProject Space junk would go into Category:Space WikiProjects).

Talk page banners

Many WikiProjects choose to create project banners to place on the talk pages of articles related to the WikiProject's topic. These talk page banners serve a few important functions. First, they serve as a recruiting tool, giving editors interested in those pages a direct link to a WikiProject where they may find similarly interested editors. Second, they can store information related to how the WikiProject views the page (e.g. assessment of the page's quality and importance to the WikiProject's topic, whether an image is required, et al.). Third, they can place the talk page into various WikiProject-related categories. These categories allow the WikiProject to take advantage of various tools that have been developed to facilitate WikiProjects' efforts (see below).

Creating a WikiProject talk page banner can range from simple to somewhat complicated. Project talk banners are generally created at Template:WikiProject Name (e.g. {{WikiProject Birds}}). The simplest way to create an adaptable talk page banner is to use the template {{WPBannerMeta}}. Using this template, a simple talk page banner might look like:

{{WPBannerMeta
|PROJECT             = Birds
 |BANNER_NAME        = {{subst:FULLPAGENAME}}
 |small  = {{{small|}}}
 |category={{{category|¬}}}
 |listas = {{{listas|}}}
|IMAGE_LEFT          = Ruddy-turnstone-icon.png
|MAIN_TEXT           = This article is within the scope of the '''[[Wikipedia:WikiProject Birds|Birds WikiProject]]''', a collaborative effort to improve Wikipedia's coverage of Birds.  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:

Module:WikiProject banner/doc
This page is a soft redirect.

Many projects also use talk page banners to store assessments of the article's quality and importance to the WikiProject. Talk page banners that use {{WPBannerMeta}} can add this functionality with relative ease using the instructions at Template:WPBannerMeta#Assessment. Basically, adding to the above template:

|QUALITY_SCALE       = extended
 |class={{{class|}}}
|IMPORTANCE_SCALE    = extended
 |importance={{{importance|}}}

Will give a talk page template that looks like:

Module:WikiProject banner/doc
This page is a soft redirect.

Where the value on the quality and importance scales will be passed to the template when it's placed on a page (see article talk pages for examples). The values for the assessment scales follow the ones developed by the Wikipedia:Version 1.0 Editorial Team. The quality scale is explained in greater detail here, and the importance scale here. One benefit of the {{WPBannerMeta}} template above is it will also automatically categorize the talk page into relevant categories (in this case Category:Stub-Class bird articles and Category:Low-importance bird articles) which will be useful for organizing project efforts and enabling various WikiProject tools.

The {{WPBannerMeta}} template supports many other optional functions including task forces, portal links, and more. You can read about these functions at the template documentation. Much of this functionality can also be generated without using the {{WPBannerMeta}} template. A set of detailed instructions is here, but is primarily targeted at those comfortable building templates.

Tag some talk pages

You've got your talk page banner, it's time to deploy it! Any editor can add any WikiProject banner to the top of any talk page (e.g. you might add {{WikiProject Birds|class=stub |importance=low}} to the top of some small article on a bird). When adding talk page banners, keep the following in mind:

The article should be related to the scope of the WikiProject. Consider adding a message on the talk page or using the |explanation= parameter if the connection is not obvious.
The presence of a project banner indicates to readers that the article has been, or will be, developed by participants in the project, and that questions about the article can be directed to participants in the project. When the project does not expect to support an article's improvement, it should not add the project's banner to that page.
While all editors are invited to tag articles for any active project, the project can also remove its banner from any article that it does not intend to support.

If you'd like to add the banner to a large number of articles that can be made into an easy list (e.g. they are all members of one or a few categories), consider asking for help from a bot operator who may be able to complete the addition with relative ease. Also note that if your template name is unwieldy to type repeatedly, you can create redirects from easier-to-type titles (e.g. Template:WPBirds) and use that template title instead.

Getting to work

Once a project has begun to attract participants, 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 participants 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.
Featured article candidates and featured article reviews: 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 participants 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.

Assessment

Quality
FA
A
GA
B
C
Start
Stub

Quality
FL
List
Redirect
Disambig
Template:Needed-Class
Template
Category
File
Portal
NA

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.

Bot-assisted assessment

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

{| class="wpb collapsible innercollapse tmbox tmbox-notice {{#ifeq:{{{small|}}}|yes|mbox-small}}"
|- class="wpb-header"
! colspan="2" class="mbox-text" | [[Wikipedia:WikiProject Birds|WikiProject Birds]]
|-
| class="mbox-image" | [[File:Ruddy-turnstone-icon.png|45px]]
| class="mbox-text" | This article is within the scope of the '''[[Wikipedia:WikiProject Birds|Birds WikiProject]]''',
a collaborative effort to improve Wikipedia's coverage of Birds.  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 = Birds}}<noinclude>
[[Category:WikiProject banners|Birds]]
</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:

Module:WikiProject banner/doc
This page is a soft redirect.

Either option will produce template code which allows the project banner to take a "class" parameter (e.g. {{WikiProject Birds|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 bird 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.

"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" may upset some editors and talk page readers); 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 participants 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:

Module:WikiProject banner/doc
This page is a soft redirect.

In order for the importance assessments to be recognized 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 in the sample input with the exact name of your project (in this case, "Birds", with an uppercase "B"), and to reset the tool when you're done.

Assessments in practice

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 participants 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 participants as possible interested in performing assessments. Clearly, it helps the project to have a participants already familiar with the system (most often through another project), and for that participants 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, participants 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 participants in 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 participants in 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 participants 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.

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 participants; 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 participants 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 using {{WPBannerMeta/hooks/peerreview}}.

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

Collaboration

Developing recommendations

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

Auxiliary features

Participant 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 participants and articles reduces the likelihood for individual group participants 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 participants 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 participants, 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.

Newsletters

See Template:Newsletters for a list of circulating newsletters. They can be freely used as a foundation for a new one.

Welcoming templates

Welcoming templates can encourage new participants by recognizing their decision to join the project. Some examples of welcoming templates:

User banners and boxes

Many WikiProjects have their own userboxes which participants put in their own userpage. An example is Wikipedia awards. For more information on making a userbox, see Wikipedia:Userboxes.

Recognition and awards

A WikiProject award is awarded for work on a WikiProject, or work of substantial interest to those participants in that WikiProject.

During the span of their existence most WikiProject participants will award other members in the project for their hard work by using the various general purpose barnstars which cover in broad strokes the tasks common to a given WikiProject, which include (but are not limited to) article development, cleanup and organizations of articles, lists and categories, copy editing of articles and lists, etc. While the existing pool of general barnstars covers these fields well, some projects have elected to create unique barnstars or other awards of similar status for use in their project to cover contributions specific to the project's scope.

Awards created specifically for a project typically use the basic barnstar design already in use for common awards and customize the given star chosen with an image that is specific to the project in question. While many existing project awards have been created in this way the project also has the option of adopting an entirely unique design for its purpose. One example is the Robotics Barnstar used by WikiProject Robotics, which forgoes the use of the barnstar in favor a set of gears. In addition to the creation of a unique wikiproject award, members of the wikiproject will also need to agree on a set of criteria to use when deciding whether or not to hand out the award, keeping in mind that the project's criteria for awarding its own award need to specific enough to the project to cover its subject matter but broad enough so that all members can reasonably satisfy the criteria for earning the award.

Rarely, projects may deviate from these standard criteria for introducing and awarding a project award by reserving the barnstar or other designated project award in question for use only under very specific circumstances. One example of a project using unique criteria for its project's award is WikiProject Philosophy, whose Star of Sophia award is "not presented by individuals, but by acclamation". Another example is the Military history WikiProject, which instituted a multi-tier award system in which contributors who earn the WikiChevrons (the project's base award) are eligible for the WikiChevrons with Oak Leaves, an award of high honor than the standard WikiChevrons. As before, projects wishing to implement a unique award system will need to obtain consensus from their members to move forward with such a system, and the project will need to decide by what criteria they will distinguish the base award from the higher held award (if any). Projects that implement a multi-tier award system should keep in the mind that the criteria for the higher held award should be broad enough that any project member can reasonably expect to obtain the award, but specific enough to the project that its members will recognize the significance of earning the higher held award.

Control and organization

Coordinators

While Wikipedia in general, and WikiProjects in particular, are usually very egalitarian with no clearly-defined chain of command, some projects have benefited from instituting a certain hierarchy within their participant base. This is achieved by appointing "coordinators", users who have agreed to take on an increased role in their project's activities. Coordinators are not usually endowed by their project with any special "executive" powers; while some projects reserve certain functions or duties to its coordinators (such as closing A-Class reviews), in other cases, coordinators have no inherent authority whatsoever.

The primary responsibility of any project's coordinators is the maintenance and housekeeping work involved in keeping their project and its internal processes running smoothly. In a large project it is easy for people to assume that someone else is doing whatever maintenance tasks (circulating and updating newsletters, maintaining templates, updating todo lists and tasks, etc.) need to be done, and in this confusion things can easily be neglected unless a specific group has been tasked with ensuring that these tasks are completed. Coordinators are often listed as the main points of contact within a project, for both external and internal queries. A coordinator's voice is often, by virtue of their position, granted considerable weight in internal discussions, enabling coordinators to take the lead in drafting project guidelines and visions, and overseeing the implementation of those decisions; however coordinators are not arbitrators or "leaders" of a WikiProject — all such decisions are still made by community consensus.

Coordinators cannot be "forced" on an unwilling WikiProject — there must be consensus amongst its participants that the introduction of a coordination system will benefit the project. There are several factors to consider:

Size of the project: Larger projects that deal with a broad topic, or projects that have grown enough to warrant the creation of task forces, may have a need for coordinators to ensure that everyone is operating toward the same general goal.
Potential for growth: Some projects are so small the potential for their growth is slim at best, and as a result the articles within the scope can be managed effectively by the project participants with no need for coordinators. Other projects are so large that they rely on satellite projects to help reduce the overall workload, as a result may not need coordinators since the more vigorous editing done by the project is through its associated projects.
Participants: Projects that have a small base of participants may lack the contributors to effectively run a coordinator department.

Coordinators are typically elected by simple approval vote and serve in coordinator capacity for a period of time determined by the project (usually 6-12 months per election cycle). The number of coordinators may grow or shrink depending on the size of the project and the addition of any task forces to the project. If a project is very large and has a large number of coordinators, they may appoint a "Lead Coordinator". The user who receives the most votes during an election cycle typically becomes the project's Lead Coordinator, while those who occupy the remaining coordinator positions are known as Assistant Coordinators or simply Coordinators. Within WikiProjects that have implemented a coordinator system, project members or former project coordinators may occasionally make a motion to elevate a former coordinator or lead coordinator to the position of "Coordinator Emeritus". Those elevated to the position of coordinator emeritus within their project have typically displayed extraordinary dedication to their project, and have been elevated by simple approval vote of the project members to allow the project in question to continue to benefit from their help and experience. Projects that have a coordinator emeritus usually declare that the position confers no special responsibility and that the position is held for as long as the coordinator emeritus wishes.

Projects that have implemented a coordinator system usually list the expected responsibilities for the coordinator(s) of the project in question as well as the users serving as coordinators on the main project page or on a dedicated subpage, to allow easy recognition of these users around the project. If the project in question has approved the use of a designated insignia for its coordinators then such pages may also include the insignias used by the project to denote both their current coordinators and their position. Typically, insignias (if present) reflect the nature of the project in question and are by tradition presented to coordinators following an election, however projects are not required to use any official insignias for their coordinator base and editors are not required to display any coordinator insignia presented if they do not wish to. Typically, projects that make use of an coordinator insignia have one for regular coordinators, one for the lead coordinator, and one for the coordinators emeriti (if present).

Inter-WikiProject relations

Common pitfalls

Trying to do too much too quickly

The most critical task for a new project is figuring out how to work together. As part of this, editors need to learn how to edit articles together, which involves identifying both content and non-content strengths (e.g., someone with easy access to excellent sources, and someone that knows how to format citations correctly). Editors also need to learn to communicate with each other on the project's talk page. To facilitate this process, it helps to propose a short series of achievable tasks early in the group's existence. By focusing the efforts, the group is more likely to work together, and to feel afterwards like the group successfully achieved a shared goal.

Depending on the project's focus, initial tasks might be article-related (e.g., clean up a key article, create a navigation template to connect a series of articles, find and nominate potential good articles) or infrastructure-related (e.g., make a list of the ten most important articles to the project, clean out an overburdened category, design a project banner, list categories of particular interest to the project) or some of both, but they should be concrete, specific, measurable, clearly articulated and, taken together, not too complex or too time-consuming. To encourage other participants to stay on task, individual editors can provide a short status report every few days about what they have accomplished and how it relates to the initial goals.

Trying to solve every problem at once, however, leads to fragmentation of effort and leaves editors feeling isolated. Taking on complicated tasks results in editors feeling like they have failed. Taking on enormous or lengthy projects leads editors to conclude that the project is unable to complete anything (as will a failure to report what individual editors are doing and ultimately what the group has achieved).

Having an overly narrow scope

A WikiProject needs to be broad enough to maintain interest and keep participants active. If the scope is too narrow, there will be very few articles within its scope. After those are brought up to a reasonable standard, the participants will quickly get bored with polishing a small number of articles. Bored editors leave.

It may also be difficult to attract enough participants to a project with a very narrow scope. While a project dedicated solely to tulips may interest some editors, a project with a broader scope, such as the Lily family or even all flowering bulbs (expanding the scope to include amaryllis, daffodils, irises, and more) might be more likely to attract a sustainable number of participants.

Most projects need at least 100 articles to work on; the largest and most active projects each have more than 10,000.

Not recruiting enough participants

Depending too much on a few participants

Getting into disputes

Two particular kinds of disputes destroy WikiProjects: conflict among participants, and conflict with other projects or editors. Either kind of dispute alienates editors and reduces the capacity for productive work.

Conflict between participants. WikiProjects are fundamentally social endeavors. If your group doesn't work well together, then the project is likely to fail. Fights between participants may start on an article's talk page and spill over to the project's pages. It is helpful to address these problems promptly, calmly, and consistently.
Conflict with other WikiProjects or unaffiliated editors. No project can control another project or other editor: No project can demand that another project support an article, change its scope, quit working on an article, or otherwise do what you want. Disputes may arise between projects or outside editors over formatting, such as the preferred system for organizing an article or the contents of a template. Disputes may also arise over quality standards. For example, WikiProject Medicine has higher standards for sources than WikiProject Alternative medicine, which uses the normal standards for reliable sources. WikiProject Military History has long had much higher standards for article assessment than the average project. In disputes with another project or with editors outside your project, your only effective tool is negotiation. If you need the cooperation of another project, approach them in a spirit of cooperation and look for appropriate compromises.

Violating policies

Policies, guidelines, and articles belong to the whole community, not to WikiProjects or individual editors. WikiProjects may not demand that editors abide by the project's "local consensus" when that conflicts with the community-wide consensus.

If a project chooses to write an advice page, such advice should not directly conflict with the site-wide advice pages.

Inappropriate exclusivity

Nearly all projects maintain a list of participants (sometimes incorrectly referred to as "members"—WikiProjects are not stand-alone organizations), and the definition of a "real" participant is occasionally a source of contention in some poorly run projects. Broadly speaking, neither those participants whose names are on a project's list nor those "charter members" that supported its initial creation have any special powers or rights compared to other editors. In fact, in nearly all projects that elect coordinators, editors that have participated in some small way, but haven't yet placed their names on the formal participant list, are even allowed to vote on an equal basis with listed participants.

In part, this is due to the fact that nearly all participant lists are inaccurate. Rather than dramatically increasing bureaucratic overhead to maintain current lists, and then trying to restrict participation to those editors that list their names in a particular place (which would be against Editing and Ownership policies, anyway), projects simply consider any editor currently involved in its work to be a participant. This highly practical approach prevents the inappropriate inclusion of editors that listed their names but have since left Wikipedia entirely or have moved on to other areas, as well as preventing rejection of valuable participants that didn't bother to sign the list, didn't know that such a list existed, object to such lists, or weren't yet sure that they wanted to publicly commit to the project.

All editors that approach a project with comments, questions, or suggestions should be welcome and treated courteously, as valuable potential participants or current participants that simply haven't taken the step of signing a designated page. To make your project a welcoming, friendly, and ultimately successful group, avoid saying things that will be received as excluding these editors, such as "Thank you for adding your thoughts for the project participants to consider" or "We should keep this discussion among existing project participants."

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 (e.g. {{todo}} and custom versions thereof

Some of these also include information about Task Forces

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 Birds 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, known as an eponymous category—in this case Category:WikiProject Birds. The category should be placed under one of Category:WikiProjects's subcategories (e.g. Category:Science WikiProjects) instead of under Category:WikiProjects directly. Some WikiProjects may be found within a "parent" WikiProject's enpoymous category (e.g. Category:WikiProject Fauna), although this is not required and may make finding the "child" project more difficult within the Category:WikiProjects hierarchy. It is generally not a good idea to place mainspace articles directly into a project's eponymous 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 Birds articles). This can have a number of different subcategories:
  - Article assessment requires a Category:Bird articles by quality (and, optionally, a Category:Bird 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 bird articles and Category:B-Class bird articles for quality assessments.
- Peer reviews and collaborations will usually require pairs of categories for current and archived articles (e.g. Category:Requests for Birds peer review and Category:Old requests for Birds 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 participants; this would generally be named in the form Category:WikiProject Birds participants, Category:Harry Potter task force participants‎, or Category:French Polynesia work group participants‎, as appropriate. The category should be a subcategory of both the eponymous category and Category:Wikipedians by WikiProject (with a sort key for the name of the WikiProject's topic), and may sometimes be populated through a userbox.
The largest WikiProjects will often acquire a number of other subcategories of their WikiProject category, 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.

v t e WikiProject Council
WikiProject guides	WikiProject Council Talk Guidelines/Intro WikiProjects Task forces Technical notes Assessment FAQ Dealing with inactive WikiProjects Work via WikiProjects
Directories and summaries	Directory Proposals Deletion Signpost Shortcuts Popular pages Database reports Watchers
Culture and the arts	Arts Music Performing Plastic Visual Broadcasting Crafts and hobbies Entertainment Games and toys Food and drink Internet culture Language and literature Biography Linguistics Media Philosophy and religion Sports
Geographical	Bodies of water Cities Countries Africa Americas Asia Europe Oceania Landforms Maps Parks, conservation areas and historical sites
History and society	History and society Business and economics Education Military and warfare Politics and government Transportation
Science, technology and engineering	Science Biology Chemistry Economics Geosciences Information science Mathematics Medicine Meteorology Physics Space Technology Time
Wikipedia assistance and tasks	Contents systems Maintenance Files Article improvement and grading Classroom projects WikiProjects