ৱিকিপিডিয়া:WikiProject Council/Guide/WikiProject

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 Birds, you would create the page at Wikipedia:WikiProject Birds.

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 Birds WikiProject!

; Goals
* Improve Wikipedia's coverage of Birds.
* Create guidelines for articles about Birds.

; Scope
* The project covers all articles about Birds and their cultivation and use.

== Members ==
# {{User|MyName}} (interested in everything about Birds)

== Open tasks ==
* ...

== Categories ==
* [[:Category:Birds]]
* ...

== Templates ==
* ...

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

{{Wikipedia policies and guidelines|state=collapsed}}
{{WikiProject Footer}}

[[Category:WikiProjects|Birds]]

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

In general, a new WikiProject page should be kept as simple as possible, and should be permitted to grow organically. While it may be tempting to create a page with dozens of rarely used sections of boilerplate, this is usually a bad idea; a small project usually cannot focus on many areas at once, and an excessively complex structure can discourage potential new members—particularly if they're joining their first WikiProject!

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 members to make up for attrition; any project that fails to do this will eventually collapse.

How, then, to recruit these precious participants? By far the most effective method is through the use of a project banner template. The more sophisticated forms of these include a variety of additional features to cope with the needs of larger projects; but, for a project that's just starting off, a simple banner may be sufficient. Supposing, again, that you had started a "WikiProject Birds", you would choose a suitable template name (you are strongly encouraged to use Template:WikiProject Project, so Template:WikiProject Birds in this example. You can easily create redirects from easier-to-type titles like Template:WPBirds, etc) and create it with some simple contents:

{| 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.
|}<noinclude>
[[Category:WikiProject banners|Birds]]
</noinclude>

Which produces:

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

{{WPBannerMeta
|PROJECT             = 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.
}}

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 members is through direct invitation. If there are other editors who are highly active in working on the project's topic, they should be identifiable by looking at the histories and talk pages of the articles; leaving them polite messages asking them to take a look at the newly active project will often produce an influx of new members. In practice, however, this method cannot match the performance of talk page banners in bringing in large numbers of new members, and is more suited towards attracting editors of particular interest, such as subject-matter experts, to the project.

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

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 members, may serve as a mission statement for active members, 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 members 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 members, 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 members on particular articles is the creation of a central list of open tasks. For smaller projects, this will often take the form of a simple section on the project page (sometimes using the {{todo}} template, although this creates additional subpages which may not be needed); larger projects will usually create a special template (which may be arbitrarily complex).

There are a number of different items which are usually included on project task lists:

Announcements

General announcements of important discussions and major tasks being undertaken. This may not be necessary for a small project—where such points can be better raised on the project's talk page—but becomes more important as the project grows and the traffic on the discussion page increases.

FACs and FARs

One of the most important items to announce to the project; particularly for a younger and smaller project, a successful FAC can be a great morale booster—but will often require the assistance of multiple project members to succeed.

Peer reviews

Requests for peer reviews; these can be project-specific peer reviews, if the project has adopted such a process, or selected entries from the main peer review page if it has not.

Requested articles

Articles which do not yet exist, but which should be created. These can often be culled from existing lists or navigational templates related to the project's scope.

Cleanup and expansion requests

These can be added manually, or collected from existing cleanup categories.

Unlike the first three categories—the size of which is generally limited—the last two can grow very quickly. It is usual, in this case, to create "overflow" lists from which entries may be rotated onto the main list as needed, and to limit the central lists to a dozen or two entries of each type. For example, a complete list of articles which need to be created may be collected on a subpage (such as Wikipedia:WikiProject Trains/Todo/Write); this list may grow to include hundreds of entries, which would be impossible to place in a reasonably-sized template. In this case, a selection of entries from this list—as well as a link to the list itself—is placed on the project's task list, to avoid overwhelming viewers.

Assessment

Quality

সাঁচ:FA-Class

সাঁচ:A-Class

সাঁচ:GA-Class

সাঁচ:B-Class

সাঁচ:C-Class

সাঁচ:Start-Class

সাঁচ:Stub-Class

Quality

সাঁচ:FL-Class

সাঁচ:List-Class

সাঁচ:Redirect-Class

সাঁচ:Disambig-Class

সাঁচ:Needed-Class

সাঁচ:Template-Class

সাঁচ:Category-Class

সাঁচ:File-Class

সাঁচ:Portal-Class

সাঁচ:NA-Class

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

One of the most common methods used by WikiProjects to monitor and prioritize their work is that of assessing the articles within their scope. The de facto standard for these assessments is the Version 1.0 Editorial Team's assessment scale (shown at left). A number of other classes have become de-facto additions to the 1.0 assessment scale, covering lists, redirects, portals, disambiguation pages and more. The full list of these additional classes is shown to the right. Some projects, such as The Beatles WikiProject, have added additional levels to account for more unusual circumstances.

A very small or less-active project can keep a hand-compiled table of assessments; as the number of articles increases, however, a specialized process becomes necessary. The first stage of this is the creation of a subpage (sometimes known as an "assessment department") for the assessment work (this is conventionally at Wikipedia:WikiProject Project/Assessment, although there is no hard-and-fast rule); these can take a number of different forms, some more formal than others (see, for example, the Military history and Tropical cyclones pages). However, the essential limitation—that of the hand-compiled list—requires a more sophisticated approach: bot-assisted assessments.

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:

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

সাঁচ:High-importance

সাঁচ:Mid-importance

সাঁচ:Low-importance

সাঁচ:NA-importance

Some projects also make importance assessments. It should be noted, however, that these tend to be more controversial (since calling articles "unimportant" may upset inexperienced editors); as a result, some projects (such as Military history) do not assess importance, while others (such as Biography) only undertake importance assessments for a limited set of articles and use the term "priority" to decrease perception problems.

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

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

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

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

In order for the importance assessments to be recognised by the assessment bot, you will need to create a category like Category:Project articles by importance and a number of subcategories. If you are an administrator, you can use an automated script found here to automatically create all the necessary categories for both the importance and quality scales for any particular project. Just make sure to replace "Foobar" by the exact name of your project (in this case, "Birds", with an uppercase "T"), 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 members will still need to go over the assessed stubs to ensure that they are assessed correctly. Often, it is the case that an article will have been expanded beyond stub level, or been incorrectly classified as a stub in the beginning, resulting in the tools incorrectly assessing the article.

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

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

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

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

Peer review

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

Another very common process for a WikiProject to undertake is the peer review of articles. This is usually not a true peer review in the academic sense, but is instead a review by project members; such peer reviews are invaluable in obtaining constructive commentary on an article, and are particularly helpful for articles which are headed towards featured article candidacies. Project peer reviews are usually more helpful than Wikipedia-wide ones, both because there is a greater chance of encountering a reviewer with some knowledge of the topic, and because it is much easier for project members to notice new requests without the need to filter out the vast majority of ones not related to their area of interest.

For very small projects, an informal system of requesting reviews on the project's primary talk page may suffice; as a project grows, however, it is usually appropriate to create a dedicated page for the peer review process (such as the military history or biography ones). This page typically includes a brief section of instructions, followed by transcluded subpages for the individual reviews; these subpages are also linked from the project banners, where the presence of a link is controlled by a template parameter (often peer_review=yes). A {{WPBannerMeta}} banner can easily add this functionality by 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

এই প্ৰবন্ধৰ বিষয়ে বিতংভাৱে জানিবৰ বাবে, 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

Member communication

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

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

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 members 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 members of that WikiProject.

Control and organization

Co-ordinators

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 membership. This is achieved by appointing "co-ordinators", users who have agreed to take on an increased role in their project's activities. Co-ordinators 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. Co-ordinators are often listed as the main points of contact within a project, for both external and internal queries. A co-ordinator's voice is often, by virtue of their position, granted considerable weight in internal discussions, enabling co-ordinators to take the lead in drafting project guidelines and visions, and overseeing the implementation of those decisions; however co-ordinators are not arbitrators or 'leaders' of a WikiProject — all such decisions are still made by community consensus.

Co-ordinators cannot be 'forced' on an unwilling WikiProject — there must be consensus amongst its membership that the introduction of a co-ordination 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 members with no need for coordinators. Other projects are so large that they rely on satelite projects to help reduce the overall workload, as a result may not need co-ordinators since the more vigorious editing done by the project is through its associated projects.
• Membership: Projects that have a small membership may lack the contributors to effectively run a co-ordinator 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 co-ordinators, they may appoint a 'Lead Co-ordinator', a position commanding considerable respect throughout the project. The user who recieves the most votes during an election cycle typically becomes the project's Lead Co-ordinator, while those who occupy the remaining co-ordinator postions are known as Assistant Co-ordinators 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 members 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 members 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 members will quickly get bored with polishing a small number of articles. Bored editors leave.

It may also be difficult to attract enough members 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 (Birds plus many kinds of lilies), 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 members.

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 members

অতিৰিক্ত তথ্য: WP:INACTIVEWP

Getting into fights

Two particular kinds of fights destroy WikiProjects: fights among members, and fights with other projects. Either kind of fight alienates editors and reduces the capacity for productive work.

• Fighting between members. WikiProjects are fundamentally social endeavors. If your group doesn't work well together, then the project is likely to fail. Fights between members 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.
• Fighting 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 members, 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 members of the project, and that questions about the article can be directed to members of 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 "members" or "participants", and the definition of a "real" member is occasionally a source of contention in some poorly run projects. Broadly speaking, neither those members 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 membership list, are even allowed to vote on an equal basis with listed members.

In part, this is due to the fact that nearly all membership 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, most projects simply assume that any editor currently involved in its work is a member. 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 exists, 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 members or real members 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 members to consider" or "We should keep this discussion among existing project members."

Technical notes

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

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

Some of these also include information about Task Forces

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—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. If there is a "parent" WikiProject with a category (e.g. Category:WikiProject Fauna), the new category should be made a subcategory of that as well. It is generally not a good idea to place articles directly into this category; for all but the smallest projects, they will quickly overwhelm the internal pages, making them quite difficult to locate.
• Once the project begins to develop article-related processes, such as assessment or peer review, it is appropriate to create a subcategory for the various articles being tagged into them; the conventional name for this is formed by appending "articles" to the project name (e.g. Category:WikiProject 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 members; this would generally be named either Category:WikiProject Birds participants or Category:WikiProject Birds members. The category should be a subcategory of Category:Wikipedians by WikiProject, and may sometimes be populated through a userbox.
• The largest WikiProjects will often acquire a number of other categories for organizing things such as templates or archives.

Further examples of category trees in actual use can be found by browsing Category:WikiProjects; a few examples showing many of the features described above are Category:WikiProject The Beatles, Category:WikiProject Biography, and Category:WikiProject Military history.

ৱিকিপ্ৰকল্পসমূহৰ পঞ্জী

ৱিকিপ্ৰকল্প সদন

ৱিকিপ্ৰকল্পসমূহৰ অৱলোকন