ਵਿਕੀਪੀਡੀਆ:WikiProject Council/Guide/WikiProject

A WikiProject is a group of people who want to work together to improve Wikipedia. A WikiProject is not the pages they use to coordinate their work, nor is it the subject area that interests them. This page provides advice on how to organize discussions and administrative issues so that the team can work efficiently.

Initial setup

Create a project page

Once you have determined that you will create a new WikiProject (see the Guide for possibly better alternatives), you must create a base page for it. The naming convention for WikiProjects is to place them in the Wikipedia: namespace at "WikiProject Name of project" (note that the "WikiProject" prefix is considered to be a virtual namespace; thus, the first word after it is capitalized, but any others follow standard sentence case rules); for example, if you were creating a WikiProject about ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ, you would create the page at Wikipedia:WikiProject ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ.

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

{{WikiProject status}}
Welcome to the ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ WikiProject!

; Goals
* Improve Wikipedia's coverage of ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ.
* Create [[WP:PROJPAGE|advice pages]] for articles about ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ.

; Scope
* The project covers all articles about ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ and their cultivation and use.

== Partcipants ==
# {{User|MyName}} (interested in everything about ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ)

== Open tasks ==
* ...

== Categories ==
* [[:Category:ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ]]
* ...

== Templates ==
* ...

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

{{Help navigation}}
{{Wikipedia policies and guidelines}}
{{WikiProject Footer}}

[[Category:WikiProject ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ| ]]

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

List your project in the WikiProject Directory

List your project at Wikipedia:WikiProject Council/Directory. Instructions for the template it uses are here. Especially if your project is just getting started, please be careful to indicate only its current activities. You can always update it later.

Recruiting

One of the most basic aspects of keeping a WikiProject active is recruiting editors. A WikiProject must recruit new participants 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 ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ", you would choose a suitable template name (you are strongly encouraged to use Template:WikiProject Project, so Template:WikiProject ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ in this example. You can easily create redirects from easier-to-type titles like Template:WPਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ, etc.) and create it with some simple content.

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

{{WPBannerMeta
|PROJECT             = ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ
 |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 ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ|ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ WikiProject]]''', a collaborative effort to improve Wikipedia's coverage of ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ.  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.
}}

produces:

Alternatively, you can create one manually, but this is discouraged. The code

{| class="wpb collapsible innercollapse tmbox tmbox-notice {{#ifeq:{{{small|}}}|yes|mbox-small}}"
|- class="wpb-header"
! colspan="2" class="mbox-text" | [[Wikipedia:WikiProject ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ|WikiProject ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ]]
|-
| class="mbox-image" | [[File:Ruddy-turnstone-icon.png|45px]]
| class="mbox-text" | This article is within the scope of the '''[[Wikipedia:WikiProject ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ|ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ WikiProject]]''', a collaborative effort to improve Wikipedia's coverage of ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ.  If you would like to participate, you can visit the project page, where you can join the project and see a list of open tasks.
|}<noinclude>
[[Category:WikiProject banners|ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ]]
</noinclude>

produces:

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

The banner should be added to the talk page of any article within the project's scope (but see the warnings about over-tagging below). If the scope happens to be well-defined by another factor—a category, for example, or a stub type—there are a number of bots which may be able to assist in placing it (see WP:BOTREQ).

Another effective way to recruit participants 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 participants. In practice, however, this method cannot match the performance of talk page banners in bringing in large numbers of new participants, and is more suited towards attracting editors of particular interest, such as subject-matter experts, to the project.

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

Define the scope

WikiProjects have sole and absolute authority to define their scopes: A group of editors cannot be forced to support any article that they do not wish to support, or prohibited from supporting any article that they wish to support.

However, successful WikiProjects frequently have a natural scope that can be simply stated and easily understood. Stating the scope on the project page may attract new participants, may serve as a mission statement for active participants, and can ease inter-project collaboration by providing clarity about which articles the group supports. The statement of scope need not be elaborate or detailed, but it should allow prospective participants and other editors to determine whether or not any given article is likely to fall within the scope of the group's work.

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.

ਅਸੈੱਸਮੈਂਟ

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

Quality

FA

A

GA

B

C

Start

Stub

Quality

FL

List

Redirect

Disambig

Needed

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 ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ 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 ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ|WikiProject ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ]]
|-
| class="mbox-image" | [[File:Ruddy-turnstone-icon.png|45px]]
| class="mbox-text" | This article is within the scope of the '''[[Wikipedia:WikiProject ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ|ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ WikiProject]]''',
a collaborative effort to improve Wikipedia's coverage of ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ.  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 = ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ}}<noinclude>
[[Category:WikiProject banners|ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ]]
</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:

Either option will produce template code which allows the project banner to take a "class" parameter (e.g. {{WikiProject ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ|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:

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, "ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ", with an uppercase "B"), and to reset the tool when you're done.

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

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

Once assessments have been started, and a WikiProject has assessed a large enough number of articles within its scope, the assessments can become very valuable, both to advance the encyclopedic purpose of the project, as well as to ensure comparatively high morale by fostering a sense of accomplishment of the 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

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

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.

Collaboration

For more details on this topic, see Wikipedia:Collaborations.

Developing recommendations

ਮੁੱਖ ਸਫ਼ਾ: Wikipedia:WikiProject Council/Guide § Advice pages

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 WikiProject Council/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:

• WP:India
• WP:Films
• WP:Novels

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

ਹੋਰ ਜਾਣਕਾਰੀ: Wikipedia:Awards by WikiProject

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

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 six months). 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. Projects that have implemented a coordinator system usually list 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.

Inter-WikiProject relations

ਮੁੱਖ ਸਫ਼ਾ: Wikipedia:WikiProject Council/Guide/Inter-WikiProject

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

ਹੋਰ ਜਾਣਕਾਰੀ: WP:INACTIVEWP

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

ਹੋਰ ਜਾਣਕਾਰੀ: WP:CONLIMITED

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.

Over-tagging

ਇਹ ਵੀ ਦੇਖੋ: Wikipedia:WikiProject Council/Guide § Article_tagging

Many WikiProjects use banner templates to label the talk pages of articles that are within the scope of their projects. Project banners advertise the project to potential participants, and, in some cases, adding a project banner to a new article's talk page can also have the effect of alerting the project to the existence of the new article.

New projects do best when they focus on identifying the Top- and High- priority articles. Assess them (if your project participates in the assessment project) and start improving those articles. Tagging articles can distract new projects from more important tasks. Please consider these common-sense issues when deciding whether to place a project banner on a page:

1. The article must be related to the scope of the WikiProject. Please consider adding a message on the talk page or using the |explanation= parameter if the connection is not obvious.
2. Project banners on the talk page should not be substitute for, or simply duplicate, Wikipedia's categorization system. To correctly identify an article as being related to a topic, place the correct category in the article itself.
3. 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.
4. While all editors are invited to tag articles for any active project, the project has the right to remove its banner from any article that it does not intend to support.

The Wikipedia 1.0 Editorial Team uses the assessments provided through project banners to do an automated screening of articles for possible inclusion. For the purposes of the Wikipedia 1.0 Editorial Team, the number of projects that tag an article has no effect on whether an article is selected.

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 ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ 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 ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ. 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 ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ 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 ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ peer review and Category:Old requests for ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ 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 ਕੁਆਂਟਮ ਭੌਤਿਕ ਵਿਗਿਆਨ participants, Categpry: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.