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

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

চমুপথবোৰ: WP:PROJGUIDE WP:COUNCIL/G

ৱিকিপ্ৰকল্প সদন edit · changes

WikiProject guide
মুখ্য পৃষ্ঠা	+ বাৰ্তা
ভূমিকা(ইং)
ৱিকিপ্ৰকল্পসমূহ
কাৰ্যনিৰ্বাহক গোট
কাৰিকৰী খুটিনাতি(ইং)
Directories
ৱিকিপ্ৰকল্পসমূহ
প্ৰস্তাৱসমূহ

This page is about organizing and running a WikiProject. It should be noted, however, that coordinators of WikiProjects are not limited to these methods. Individual projects will often develop more unusual features that depend on peculiarities of the projects' scope or activities; the best ways to discover these is through innovative experimentation, or to observe what successful WikiProjects are doing. It is unlikely that this guide will ever include every possible idea that a project may have used.

The guide is primarily concerned with topical WikiProjects—that is, WikiProjects whose goal is the improvement of articles within a certain subject area. Maintenance WikiProjects, such as stub-sorting, disambiguation, or other cleanup tasks, have a distinctly different structure and organization of activity, so much of the advice given here may not apply to them.

What is a WikiProject?

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

A WikiProject may also be a focal point for building ties between Wikipedians interested in a certain topic area, and the broader community interested in that topic area; establishing partnerships, welcoming and mentoring new Wikipedians, etc. In this respect, the role of a WikiProject may overlap with the role of a Wikimedia Chapter.

The pages of a WikiProject are the central place for editor collaboration on a particular topic area. Editors there may develop criteria, maintain various collaborative processes, keep track of work that needs to be done, and act as a forum where issues of interest to the editors of a subject may be discussed.

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

A WikiProject is fundamentally a social construct; its success depends on its ability to function as a cohesive group of editors working towards a common goal. Much of the work that members must do to sustain a successful WikiProject (quality assessment and peer review in particular, but almost anything beyond the actual writing of articles) is tedious, often unrewarding, and usually unappreciated. To be effective, a WikiProject must foster not only interest in the topic of the project, but also an esprit de corps among its members. When group cohesion is maintained—where, in other words, project members are willing to share in the less exciting work—a WikiProject can muster the energy and direction to produce excellent articles systematically rather than incidentally.

Before you begin

The advice presented in this section is intended primarily for projects that are just starting up—or are being brought back to activity—as well as for editors who may be considering creating a new WikiProject; however, anyone involved with WikiProjects might find some items of interest.

Check for existing proposals

This is pretty simple: Go to WikiProject Proposals, and see if anyone else is already proposing this. Search through all the archives (listed here: no archives yet (create)) to see if it has been proposed before.

Identify any parent projects

Before you even begin, you should identify any related projects. If you have a good idea for a viable project, there's a good chance that someone else has had the idea as well, so the project already exists. If it's truly a new idea, then members interested in your subject are likely to be involved in related projects, and they may be able to help you set up a new project.

Please take the following steps before you do anything:

Examine the WikiProject Directory and see if you can identify any projects which might be "parents" for yours. For the example of the proposed WikiProject Tulips, you might be looking up WikiProject Netherlands in the Geographic section of the directory, and WikiProject Horticulture and Gardening from the Science section.
Examine the Portal Directory to find related projects.
Check the talk pages of all key articles to see whether they have been tagged as being within the scope of any related projects.

What to do with the information:

If a closely related group already exists, even if it is inactive, you should join that project rather than starting yet another WikiProject. Any editor can "revive" or "take over" an inactive or semi-active WikiProject simply by joining the project.
If your area fits neatly within an existing group with a larger scope (e.g., your favorite video game vs WP:WikiProject Video games), then please join that project, rather than starting yet another WikiProject.
- If work on the subject requires so much discussion that it might overwhelm the larger, existing group, then your group can become a focused WP:Task force under that project. Task forces have all the benefits of regular projects, such as a dedicated talk page for discussion and article coordination, but many fewer administrative hassles.
- It should go without saying that if your proposed project has a parent, you should discuss its potential creation on that parent project's talk page.
- Many small, inactive WikiProjects were started before the task-force structure was formalized. Inactive groups with a limited topical scope should normally be turned into task forces of their "parent" WikiProject.

If no such existing projects are found, then your next step is to propose a new WikiProject.

Identify the best scope

Next, identify the best scope for your project. Successful WikiProjects have a scope that is natural and broad enough to attract and sustain editor interest. For example, are Tulips too small a project scope, such that it might only ever have a few dozen articles and six project members (some of whom don't do much)? Either of those criteria should be enough to make you think that maybe a larger scope would be better. You might be able to get a more reasonably sized project by including the entire Lily family, which includes tulips, or all flowers, or the larger subject of gardening and horticulture.

The risks of a narrow scope are:

Not enough people: Your group may die from administrative overload, and become one of the more than 350 Inactive WikiProjects.
Not enough pages: People will quickly complete the work and get bored. Your project may die from administrative overload, and likewise become inactive.
Too much overlap: If the scope is too closely related to an existing project, then having separate projects is usually inefficient and counterproductive, because you wind up dividing the few interested editors across multiple projects. This approach maximizes administrative hassles and minimizes collaboration. However, there is no rule that prohibits two separate groups of editors from being interested in the same articles.

How to estimate the number of pages in your proposed scope

Go to the main article. Click on "What links here", and see how many articles are connected to this one. This is probably your number, unless you limit the scope in some way (e.g., only including significant Tulip growers (not just fanciers) from before 1900 in the Biography category).
Look in the categories associated with your key articles. The proposed WikiProject Tulips, for example, would want to consider categories like Category:Flowers and Category:Tulipa.

Having considered the probable size of the scope, ask yourself, "Is this a 'natural' scope?" Will other people be able to easily understand what kind of articles the group is working on? WikiProjects are allowed to have strange, arbitrary, or unpredictable scopes ("Tulips, except for my least favorite species, plus my favorite photo software"), but we strongly recommend that you adjust or expand the scope to be more sensible.

At the end of this step, you should know approximately how many articles are likely to be within the project's scope, what the names of the key articles and categories are, and how to describe the scope briefly. That information will help you determine the best structure.

Identify the best structure

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

Topic coordination: This format is appropriate if you want to co-ordinate across about a dozen or so pages, or for temporary, one-time tasks. See the separate section below for details.
Task force: This format is appropriate if your scope involves a few dozen to a few hundred pages. A task force uses most of the administrative structure of their parent project, but works together as a smaller group. The fastest way to start a task force is to join the parent WikiProject(s), and ask if they can help you form a task force. Some WikiProjects have a more developed framework for dealing with sub-groups like task forces; others will be unfamiliar with them. However, most WikiProjects are happy to have someone who is keen to start a task force, even if the project doesn't currently have any task forces in place.
WikiProject: This format is best for topics with thousands, or at least several hundred, of pages in the proposed scope. You'll still want to investigate any related projects, because they may already have a task force covering the same topic.
Inter-WikiProject coordination: If your scope was too large, but you're still keen, you'll probably want, instead, to identify potential child WikiProjects, and try to help them co-ordinate; this doesn't require a WikiProject in itself. Talk to the potential child WikiProjects about co-ordination, and see what sort of response you get. Be careful not to try to dictate to them; they could be sensitive about you appearing out of nowhere and wanting to assimilate them. If this is the format you choose, the rest of this document, while good background reading, is not essential (although it may help you not to look like an idiot).

Identify potential members

A WikiProject is the people, not the articles or the pages that help the people work together. You should consider whether enough people want to work together to make this possible. You might already know people who are interested, or you may find potential participants by contacting related groups, posting messages at articles that are likely to be top-importance to your proposed group, or by directly contacting editors that are working in this area.

Topic coordination

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

Talk page information

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

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

Topic coordination on a talk page

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

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

Inter-WikiProject coordination

চমুপথ: WP:WikiProject coordination

Article tagging

WikiProject banner tags or stub templates?

WikiProject assessment banner tags and stub templates often seem to serve the same purpose, yet they have distinct functions. While a banner tag marks an article specifically for a WikiProject, the aim of stub templates is to mark small articles uniformly across the whole of Wikipedia. As such, there is a large effort to coordinate stub use across all WikiProjects and also those articles not covered by individual subject projects (this is the main reason why there is a semi-formal proposal process for stub templates and categories). Banner templates, on the other hand, can be altered as an individual WikiProject sees fit, and — since they can be used to tag all articles relating to a WikiProject, and not just stubs — they are the recommended tagging method for individual WikiProjects. See Wikipedia:Stub#Stub types, WikiProjects, and Assessment templates for more details.

Purpose of WikiProject banner tags

While many editors think that member recruitment is the primary reason for placing a project banner on an article, they are actually used in many different contexts:

The tags place articles into categories that project members use to find articles that they want to work on.
The tags are used to check recent changes (a sort of watchlist for the articles the group cares about).
They are used to produce statistical reports about the quality of articles, which allow the group to monitor their progress.
The tags allow the WP:1.0 team's assessment process to measure the size/scope of projects and to rank articles for inclusion in offline releases of Wikipedia articles.
Article Alerts uses information in the tags to produce an automatically updated list of WP:Articles for deletion, WP:Proposed deletions, and other time-sensitive news about tagged articles.
Cleanup listings uses tags to produce a comprehensive list of all clean-up tags in a project's articles.
Walls of Recognized Content uses tags to create lists of high-quality articles.
and several other automated processes.

WikiProjects do not own articles

Many articles will be tagged by more than one WikiProject. This is particularly true of articles which deal with prominent people, as those articles may be tagged by WikiProjects for biography, their places of residence, their professional field, and any other activities they may engage in. Placement of any relevant banner should generally be accepted, as each project may have unique resources and be willing to improve and monitor the article. One group may not prohibit another group from showing an interest in an article.

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

In 2007, some editors agreed to limit "WikiProject country" banners on articles about a city, especially if the city has changed hands several times over the course of history: if there is disagreement, then only the Wikiproject for the city's current country will tag the article. For example, though the Germans occupied France during World War II, it would not be appropriate to put articles about French cities under WP:WikiProject Germany. For more information, see the 2007 consensus discussion.

Article editors do not own WikiProjects

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

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

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

Overtagging is disruptive

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

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

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

Inter-project collaboration

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

You could also approach relevant projects directly for pages of interest to discuss collaboration. You can use {{CotM}} on article talk pages to highlight a joint Collaboration of the Month.

Advice pages

Many large WikiProjects eventually collect some advice about how to apply Wikipedia's policies, guidelines, and essays to their specific subject area. This advice is often excellent, and may helpfully explain the specific details of site-wide policies that are the source of the most confusion among editors.

Editors who are working on such an advice page are encouraged to carefully study the main policies, guidelines, Manual of Style, and relevant essays. The best advice pages do not conflict with the site-wide pages and avoid unnecessary duplications with site-wide pages. You can help editors by providing links to subject-specific templates, a list of information that editors should consider including in a given type of article, relevant examples, and clear explanations (e.g., reasons why editors recommend 'this' instead of 'that').

However, in a few cases, small projects have wrongly used these pages as a means of asserting ownership over articles within their scope, e.g., that all articles that interest the editors must (or must not) contain an infobox, and that editors at the article get no say in this because of a "consensus" within the group. An advice page written by several members of a project is no more binding on editors than an advice page written by any single individual editor. Any advice page that has not been formally approved by the community through the WP:PROPOSAL process has the actual status of an optional {{essay}}.

The following templates are available to WikiProjects for clarifying the distinction between WikiProject guidance and Wikipedia-wide guidelines:

Role of the WikiProject Council

There may still arise situations when there is a seemingly intractable disagreement between projects. If that happens, you can ask for advice from the WikiProject Council. This group contains people who have generally shown some ability at working with and in groups. In severe cases, using formal dispute resolution channels are available.

Use bots to save work

Several bots can automatically tag article talk pages with a WikiProject banner, as well as make some automatic assessments. Xenobot Mk V has clear instructions for making requests; or see Category:WikiProject tagging bots for a full list, as well as Category:Autoassessment bots.
AlexNewArtBot generates a report listing newly-created articles that match criteria set by the project; this is particularly useful for catching new articles not categorised properly.
User:JL-Bot generates a subpage listing the Recognized Content (Featured Articles, Good Articles, In The News, etc) of a WikiProject. See User:JL-Bot/Project content for details.
AAlertBot generates daily reports of the deletion discussions (PROD, AfD, ...) and reviewing process (FAC, GAN, ...) related to the articles of a WikiProject. See WP:AALERTS for details.
WP 1.0 bot generates tables summarizing article quality and importance statistics. It also produces daily logs of the change in article quality/importance ratings, as well as renamings, and banner tagging/untagging.
DASHBot/Wikiprojects generates a list of unreferenced biographies of living persons relevant to a project.

Dealing with inactive WikiProjects

চমুপথ: WP:INACTIVEWP

Identifying

Inactive wikiprojects will have {{inactive}} added, either directly or via the inactive parameter of {{Infobox WikiProject}}. There are several options in dealing with inactive wikiprojects. The usual procedure is to identify projects whose main page hasn't been substantively changed for several months, and whose talk page has received nothing other than routine or automated announcements, or unanswered queries from non-participants, for several months. Alternatively, you may wish to sort through the list of named participants, placing indefinitely blocked accounts and users who have made no edits to Wikipedia for long periods (e.g., over a year) under a separate heading (you may wish to notify the users that you have done so, in case they return). If no active members remain in the list, then the project is inactive.

Revival

See also the related Wikipedia Signpost article

Any editor may revive an inactive WikiProject. There are a number of things you can do to help revive an inactive or semi-active project. If you come up with something new, please list it here!

Update the project page as appropriate: replace the inactive tag with {{semi-active}}, or remove the existing semi-active tag. Archive old clutter (clean and simple is better for attracting new members), use generic WikiProject templates appropriately to organise content (e.g., {{Infobox WikiProject}}) and make use of any helpful automation the project hasn't been using (see section above).
Provide clear suggestions on what members can do, using todo lists, {{tasks}} and cleanup listings, and perhaps linking to relevant pages elsewhere. You can use the {{WikiProject help}} template, either directly or as inspiration.
Create any missing userbox, project banner, or user invite templates. See whether the assessment system for the project banner works, and fix it if not.
Notify existing participants of your efforts and invite them to contribute, to make suggestions, or to leave a note on the project's talk page about what they're currently editing.
To try to gain new participants, individually invite active users who have been substantively involved with the topic to join the project or watchlist its page. This can be done with a personal, handcrafted message or a standardized invitation template.
Use automation (see above) to ensure most if not all appropriate pages are tagged with the project banner, thus promoting the project to those who may be interested. (Don't go overboard with this... in general, don't tag a page not within the project's main category unless you could justify making it the project's Collaboration of the Month.)
Provide a Special:RecentChangesLinked link on the project page, using the project's article category. (For project Wikipedia:WikiProject X, this will generally be Category:X articles, Category:WikiProject X articles, or X work group articles. Try it and see.) This gives an easy way to see recent relevant talk page discussions. Example.
Seek out collaboration with related projects. Tell them that the project is active, invite them to help, and ask whether there is an article of mutual interest that both groups could collaborate on.
Notify the Wikipedia Signpost WikiProject desk of your attempt.
Respond promptly to queries and post occasional messages at the WikiProject's talk page to let people know what you're working on and how they can help.

If you have any questions about related technical issues, try the Help Desk.

Other options

If you (or someone else) has already done the above or it simply looks hopeless, consider one of these options:

Merger. Consider proposing a merger with another wikiproject. This might be a related project of a similar type, with the two projects being reconstituted as part of a new one. More commonly it might be that the inactive project could become a taskforce of a parent project. See here for instructions on notification and merging projects.
Mark as defunct. In some cases projects are simply superseded (e.g., merged elsewhere), have served their stated purpose, or have been inactive for so long that they are unlikely ever to be revived. These may be tagged as defunct rather than inactive; see the usage notes and guidelines at {{defunct}}. This tag should be used rather than {{historical}} which is reserved for failed proposals or deprecated processes.
Userfy. When project had only one active member or was never so active as to justify keeping it for the whole community to refer to, consider userfication of the project to the organizer's userspace. This is particularly useful for recently created projects that never got off the ground as it can avoid being bitey.
Deletion. In rare cases, deletion may be appropriate. This might be appropriate for completely inactive projects which have no substantive history and serve no residual purpose even without activity (e.g., due to automation or information presented). Projects must also meet the guidelines for being marked as defunct (see {{defunct}}). WP:MFD is the appropriate forum to propose this.

If you are considering taking any significant steps in this area which others might object to, take care to give appropriate notice to all parties of your proposals (including the WikiProject Council). Often it will be feasible to notify all listed participants who have been active on Wikipedia in the recent past (even if not recently active on the project). If proposing a merger, be sure to propose this at the merger target and do not take approval for granted.

Creating a WikiProject

প্ৰধান পৃষ্ঠা: Wikipedia:WikiProject Council/Guide/WikiProject

{{WikiProject}} is a boilerplate template to be used in creating a new WikiProject main page. For example, suppose the name of your new WikiProject is Foo. The first step is to create the page "Wikipedia:WikiProject Foo", and substitute this template in it by typing this text: {{subst:WikiProject|Foo}}. After saving, this code will be replaced by a skeleton for a WikiProject page which you have to adapt to the needs of your project. Some elements are in comments and will have to be uncommented, others that are unnecessary will have to be deleted or commented out. A few guidelines are also provided in the comments.

Task force

প্ৰধান পৃষ্ঠা: Wikipedia:WikiProject Council/Guide/Task forces

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