ଉଇକିପିଡ଼ିଆ:WikiProject Council/Guide
Wikipedia policies and guidelines are developed by the community to describe best practice, clarify principles, resolve conflicts, and otherwise further our goal of creating a free, reliable encyclopedia. There is no need to read any policy or guideline pages before starting editing. However, it is worth reading the Five pillars page, which contains a summary of the most pertinent principles. Although Wikipedia does not employ hard-and-fast rules, Wikipedia policy and guideline pages describe its principles and best-known practices. Policies explain and describe standards that all users should normally follow, while guidelines are meant to outline best practices for following those standards in specific contexts. Policies and guidelines should always be applied using reason and common sense. This policy page specifies the community standards related to the organization, life cycle, maintenance of, and adherence to policies, guidelines, and related pages. DerivationWikipedia is operated by the not-for-profit Wikimedia Foundation, which reserves certain legal rights (see here for a list of its policies). See also Role of Jimmy Wales. Nevertheless, normally Wikipedia is a self-governing project run by its community. Its policies and guidelines are intended to reflect the consensus of the community. RolePolicies have wide acceptance among editors and describe standards that all users should normally follow. All policy pages are in Wikipedia:List of policies and guidelines and Category:Wikipedia policy. For summaries of key policies, see also List of policies. Guidelines are sets of best practices that are supported by consensus. Editors should attempt to follow guidelines, though they are best treated with common sense, and occasional exceptions may apply. Guideline pages can be found in Wikipedia:List of policies and guidelines and Category:Wikipedia guidelines. For summaries of key guidelines, see also List of guidelines. Essays are the opinion or advice of an editor or group of editors, for which widespread consensus has not been established. They do not speak for the entire community and may be created and written without approval. Essays that the author does not want others to edit, or that are found to contradict widespread consensus, belong in the user namespace. See Category:Wikipedia essays and Wikipedia:Wikipedia essays. Other pages that can be found in the Wikipedia: namespace include community process pages (which facilitate application of the policies and guidelines), historical pages,[୧] WikiProject pages, how-to or help pages (also found in the Help namespace), community discussion pages and noticeboards. These pages are not policies or guidelines, although they may contain valuable advice or information. AdherenceUse common sense when interpreting and applying policies and guidelines; there will be occasional exceptions to these rules. Conversely, those who violate the spirit of a rule may be reprimanded even if no rule has technically been broken. Whether a policy or guideline is an accurate description of best practice is determined by the community through consensus. On discussion pages and in edit summaries, shortcuts are often used to refer to policies and guidelines. For example, WP:NOR, WP:NPOV, and WP:LIVE. Similar shortcuts are sometimes also used for other types of project page. A shortcut does not necessarily imply that the page linked to has policy or guideline status. Additionally, remember that the shortcut is not the policy; the plain-English definition of the page's title or shortcut may be importantly different from the linked page. EnforcementEnforcement on Wikipedia is similar to other social interactions. If an editor violates the community standards described in policies and guidelines, other editors can persuade the person to adhere to acceptable norms of conduct, over time resorting to more forceful means, such as administrator and steward actions. In the case of gross violations of community norms, they are likely to resort to more forceful means fairly rapidly. Going against the principles set out on these pages, particularly policy pages, is unlikely to prove acceptable, although it may be possible to convince fellow editors that an exception ought to be made. This means that individual editors (including you) enforce and apply policies and guidelines. In cases where it is clear that a user is acting against policy (or against a guideline in a way that conflicts with policy), especially if they are doing so intentionally and persistently, that user may be temporarily or indefinitely blocked from editing by an administrator. In cases where the general dispute resolution procedure has been ineffective, the Arbitration Committee has the power to deal with highly disruptive or sensitive situations. ContentPolicy and guideline pages should:
Not part of the encyclopediaWikipedia has many policies and guidelines about encyclopedic content. These standards require verifiability, neutrality, respect for living people, and more. The policies, guidelines, and process pages themselves are not part of the encyclopedia proper. Consequently, they do not generally need to conform with the content standards. It is therefore not necessary to provide reliable sources to verify for Wikipedia's administrative pages, or to phrase Wikipedia procedures or principles in a neutral manner, or to cite an outside authority in determining Wikipedia's editorial practices. Instead, the content of these pages is controlled by community-wide consensus, and the style should emphasize clarity, directness, and usefulness to other editors.[୨] These pages do, however, need to comply with Wikipedia's legal and behavioral policies. For example, editors may not violate copyrights anywhere on Wikipedia, and edit warring is prohibited everywhere, not merely in encyclopedia articles. Life cycle
Many of the most well-established policies and guidelines have developed from principles which have been accepted as fundamental since Wikipedia's inception. Others developed as solutions to common problems and disruptive editing. Policy and guideline pages are seldom established without precedent,[୩] and always require strong community support. Policies and guidelines may be established through new proposals, promotion of existing essays or guidelines, and reorganization of existing policies and guidelines through splitting and merging. Essays and information pages may be established by writing them and adding {{essay}}, {{infopage}}, or similar templates to the page. Current policy and guideline proposals can be found in Category:Wikipedia proposals, and rejected proposals can be found in Category:Wikipedia rejected proposals. All editors are welcome to comment on these proposals. Proposals
New proposals require discussion and a high level of consensus from the entire community for promotion to guideline or policy. Adding the {{policy}} template to a page without the required consensus does not mean that the page is policy, even if the page summarizes or copies policy. Most commonly, editors use a Request for comments (RfC) to determine consensus for a newly proposed policy or guideline, via the Good practice for proposalsThe first step is to write the best initial proposal that you can. Authors can request early-stage feedback at Wikipedia's village pump for idea incubation and from any relevant WikiProjects. Amendments to a proposal should be discussed on its talk page (not on a new page), but it is often appropriate and even necessary to improve a proposal in response to feedback received from outside editors. Once you think that the initial proposal is well-written, start an RfC for your policy or guideline proposal in a new section on the talk page, and including the The RfC should typically be announced at the policy and/or proposals village pumps, and you should notify other potentially interested groups. If your proposal affects a specific content area, then related WikiProjects can be found at the Wikipedia:WikiProject Council/Directory. For example, proposed style guidelines should be announced to Wikipedia:WikiProject Manual of Style. If your proposal relates to an existing policy or guideline, leave a note on the talk page of the related policy or guideline. For example, proposed style guidelines should be announced at Wikipedia:Manual of Style. Try to identify the subcategory of guideline or policy (see {{subcat guideline}}). Proposals involving contentious subjects or wide-ranging effects should normally be listed on Wikipedia:Centralized discussions for the duration of the RfC. RfCs for policy and guideline proposals are normally left open for at least one week, and sometimes as long as a couple of months. To avoid later complaints about insufficient notice, it may be helpful to provide a complete list of the groups or pages that you used to advertise the proposal on the talk page. Editors should respond to proposals in a way that helps identify and build consensus. Explain your thoughts, ask questions, and raise concerns; all views are welcome. Many editors begin their response with bold-font 'vote' of support or opposition to make evaluation easier. Editors should sign their responses. Ending a discussion requires careful evaluation of the responses to determine the consensus. This does not require the intervention of an administrator, but may be done by any sufficiently experienced independent editor (an impartial editor not involved in the discussion) who is familiar with all of the policies and guidelines that relate to the proposal. The following points are important in evaluating consensus:
Discussion may be closed as either Promote, No consensus, or Failed. Please leave a short note about the conclusion that you came to. Update the proposal to reflect the consensus. Remove the {{Proposed}} template and replace it with another appropriate template, such as {{Subcat guideline}}, {{Policy}}, {{Essay}}, {{Wikipedia how to}}, {{Infopage}}, or {{Failed}}. If a proposal fails, the failed tag should not usually be removed. It is typically more productive to rewrite a failed proposal from scratch to address problems than to re-nominate a proposal. DemotionAn accepted policy or guideline may become obsolete because of changes in editorial practice or community standards, may become redundant because of improvements to other pages, or may represent unwarranted instruction creep. In such situations editors may propose that a policy be demoted to a guideline, or that a policy or guideline be demoted to a supplement, informational page, essay or historical page. In certain cases, a policy or guideline may be superseded, in which case the old page is marked and retained for historical interest. The process for demotion is similar to promotion. A talk page discussion is typically started, the The {{disputedtag}} template is typically used instead of {{underdiscussion}} for claims that a page was recently assigned guideline or policy status without proper or sufficient consensus being established. Essays, information pages, and other informal pages that are only supported by a small minority of the community are typically moved to the primary author's userspace, rather than being demoted. These discussions typically happen on the page's talk page, sometimes with an RfC, but they may also be conducted at Miscellany for Deletion. Other pages are retained for historical reference and are marked as such. Content changesPolicies and guidelines can be edited like any other Wikipedia page. Because Wikipedia practice exists in the community through consensus, editing a policy/guideline/essay page does not in itself imply a change to accepted practice. It is naturally bad practice to write something other than accepted practice on a policy or guideline page. To update best practices: either change the practice directly (you are premitted to deviate from practice for the purposes of such change), set about building widespread consensus for your change or implementation, or a combination of both. At that point, you can then edit the page to reflect the new situation. Substantive changesTalk page discussion typically precedes substantive changes to policy. Changes may be made if there are no objections, or if discussion shows that there is consensus for the change. Minor edits to improve formatting, grammar, and clarity may be made at any time. If the result of discussions is unclear, then it should be evaluated by an administrator or other independent editor, as in the proposal process. Major changes should also be publicized to the community in general; announcements similar to the proposal process may be appropriate. If wider input on a proposed change is desired, it may be useful to mark the section with the tag The older but still valid method is to boldly edit the page. Bold editors of policy and guideline pages are strongly encouraged to follow WP:1RR or WP:0RR standards. Although most editors find advance discussion, especially at well-developed pages, very helpful, directly editing these pages is permitted by Wikipedia's policies. Consequently, you should not remove any change solely on the grounds that there is no formal record indicating consensus for it: instead, you should give a substantive reason for challenging it, and open a discussion to identify the community's current views, if one hasn't already been started. Editing a policy to support your own argument in an active discussion may be seen as gaming the system, especially if you do not disclose your involvement in the argument when making the edits. Conflicts between advice pagesIf policy and guideline pages directly conflict, one or more pages need to be revised to resolve the conflict so that all of the conflicting pages accurately reflect the community's actual practices and best advice. As a temporary measure during that resolution process, if a guideline appears to conflict with a policy, editors may assume that the policy takes precedence. More commonly, advice pages do not directly conflict, but provide multiple options. For example, WP:Identifying reliable sources says that newspaper articles are generally considered to be reliable sources, and WP:Identifying reliable sources (medicine-related articles) recommends against newspaper articles for certain technical purposes. Editors must use their best judgment to decide which advice is most appropriate and relevant to the specific situation at hand. Making improvementsPolicies and guidelines aim to describe community norms. When a norm changes there is usually a specific discussion. However when the way it works in practice as seen by experienced users is poorly described, the policy is often updated to reflect it better. As with articles, if the community disagrees it will be reverted or discussed. The question of whether to just edit and simultaneously explain, or to seek consensus on the talk page first, is a matter of judgment based upon experience. Because policies and guidelines are sensitive, users should take care over any edits; they generally need to understand what the community's approach really is, before making substantive changes to policies or guidelines, to be sure they are reflecting the communal view faithfully or making changes the community is likely to consider appropriate. NamingThe page names of policies and guidelines usually do not include the words "policy" or "guideline," unless required to distinguish the page from another. See also
Notes
Related information
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 beginThe 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 proposalsThis 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 projectsBefore 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:
What to do with the information:
If no such existing projects are found, then your next step is to propose a new WikiProject. Identify the best scopeNext, 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:
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 structureHaving identified the scope you want for your project, the next thing to consider is the best structure for the project. The typical structures are:
Identify potential membersA 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 coordinationIf 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 informationNaturally, 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 pageHere'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.
Inter-WikiProject coordinationArticle tagging
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.
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:
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.
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.
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 collaborationThere 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 pagesMany 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}}. Please tag your project's advice with these templates: Role of the WikiProject CouncilThere 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 workSee also: Wikipedia:WikiProject Council/Guide/Technical notes#Automation
Dealing with inactive WikiProjectsIdentifyingInactive 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
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!
If you have any questions about related technical issues, try the Help Desk. Other optionsIf you (or someone else) has already done the above or it simply looks hopeless, consider one of these options:
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{{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: Task forceA 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. See also
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Portal di Ensiklopedia Dunia
