Jump to content

Wikipedia:Policies and guidelines

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Dank (talk | contribs) at 03:51, 26 September 2009 (rv self; discussion has died down). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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; indeed, the largest encyclopedia in history, both in terms of breadth and in terms of depth.

This policy page specifies the community standards related to the composition, structure, organization, life cycle, and maintenance of policies & guidelines and related pages.

Role

Policies have wide acceptance among editors and are standards that all users should follow. They are often closely related to the five pillars of Wikipedia. Where a guideline appears to conflict with a policy, the policy takes precedence.

Guidelines are primarily advisory. They advise on how to prevent or avoid causing problems, and on how to apply and execute policy under specific circumstances. See List of policies and List of guidelines.

Essays are the opinion or advice of an editor or a group of editors. No formal attempt to gauge their widespread consensus has been made. Essays may be created and written by any editor. They do not speak for the entire community. Personal essays belong in the User namespace.

Community process pages facilitate application of the policies and guidelines.

Listings can be found at the List of policies, List of guidelines, and Category:Wikipedia essays. Other pages that can be found in the Wikipedia: namespace include historical pages,[1] WikiProject pages, how-to or help pages (also found in the Help namespace), community discussion pages and noticeboards.

Whether a policy or guideline is an accurate description of best practice is determined by the community through consensus. Editors are expected to use common sense in interpreting and applying these rules; those who violate the spirit of the rule may be reprimanded even if no rule has technically been broken. Major changes to a policy or guideline page are discussed first on the talk page, especially with policies, but it is acceptable to edit them directly if the edit does not make a substantive change.

Enforcement

Enforcement 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 policy pages, they are likely to resort to more forceful means fairly rapidly. You'll need to do some pretty fast talking to get away with not adhering to the consensus within policy pages, though this is not impossible, if you somehow happen to know something that many years of collective wisdom hasn't discovered yet. 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.[2]

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

Content

Policy and guideline pages should:

  • be clear and terse. Avoid esoteric legal terms and verbose dumbed-down language. Be both plain and concise. Clarity and terseness are not in opposition: direct and brief writing is more clear. Footnotes may be used for further clarification.
  • emphasize the spirit of the rule. Verbosity is not a defense against misinterpretation. Be unambiguous and specific: avoid platitudes and generalities. Don't theorize, and omit needless words, especially adjectives. If the spirit of the rule is clear, say no more.
  • maintain scope, avoid redundancy. Both purpose and scope must be clearly provided in the lead, and not merely as an aside. Content should be within the scope of its policy.[3] Policies should not be redundant with other policies, or within themselves.[4] Do not summarize, copy, or extract text. Avoid needless reminders.[5]
  • avoid overlinking. Links should be used only when clarification or context is needed.[6] Links to other policies, guidelines, or essays may inadvertently or intentionally defer authority to them. Make it clear when links defer, and when they do not.

Life cycle

Many of the most well-established policies and guidelines are closely related to Wikipedia's founding principles. Others developed as solutions to common problems and disruptive editing. Policy pages are seldom established without precedent,[7] and always require strong community support. Policies may be established through new policy proposals, promotion of essays or guidelines, and reorganization of existing policy through splitting and merging.

Current policy proposals can be found in Category:Wikipedia proposals, and rejected proposals can be found in Category:Wikipedia rejected 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. The Request for comments process is typically used to determine consensus for a new policy, via the {{rfctag|policy}} tag.[8] A proposal RfC should be left open for at least one week. Policy proposals can get early-stage feedback at Wikipedia's policy village pump.

If a proposal fails, the failed tag should not be removed. It is typically more productive to rewrite a failed proposal from scratch to address problems than to re-nominate a proposal.

Demotion

An 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 or guideline be demoted to guideline, essay, or historical page.[9]

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.

Many historical essays can still be found within Meta's essay category. The Wikimedia Foundation's Meta-wiki was envisioned as the original place for editors to comment on and discuss Wikipedia, although the "Wikipedia" project space has since taken over most of that role.

Content changes

Talk page discussion typically, but not necessarily, 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. Bold editors of policy and guideline pages are strongly encouraged to follow WP:1RR or WP:0RR standards. Minor edits to improve formatting, grammar, and clarity may be made at any time. [10]

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.

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.

See also

Notes

  1. ^ Many historical essays can still be found within Meta's essay category. The Wikimedia Foundation's Meta-wiki was envisioned as the original place for editors to comment on and discuss Wikipedia, although the "Wikipedia" project space has since taken over most of that role.
  2. ^ 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.
  3. ^ Suppose that some of the content from a dispute resolution page was copied into Wikipedia:Consensus as a great example of consensus building. Though it may be a great example, it is not a general community standard – yet several clarifying edits later, it may seem as if it were being presented as such. Or perhaps an edit is made to Wikipedia:Notability to clarify how it should be applied within a notability guideline on music. Perhaps Wikipedia:Verifiability is 'summarized' and reworded (non-substantively, of course!) in a guideline, so that editors don't have to check the longer (official, carefully-worded, more-rigorously maintained) version. All of this is scope creep. Keep policies to themselves.
  4. ^ The same redundant statement may change in one place and not in another, and though this is often not a problem in articles, with policy it lead to confusion, contradiction, and verbosity.
  5. ^ Example
  6. ^ For example, in "...are developed by the Wikipedia community to establish...", neither link is necessary. The links imply that the target pages might be important in understanding the sentence, yet the meaning is clear. The two pages provide more in-depth explanations of Wikipedia and the community, but this level of explanation is not necessary. In "Guidelines are [...]", the link implies that what follows is a summary of the linked page, which itself describes Guidelines in detail. Yet the link is just a list of guidelines.
  7. ^ Office declarations may establish unprecidented policies to avoid copyright, legal, or technical problems, though such declarations are rare.
  8. ^ An RfC can be initiated by starting a new section at the relevant talk page, and including the {{rfctag|policy}} tag along with the reasons to make the proposal a policy or guideline. Amendments to a proposal should be discussed on its talk page (not on a new page) but it is generally acceptable to edit a proposal to improve it. The {{proposed}} (for newly-written proposals) or {{promote}} (for promotion of essays or guidelines) should be placed at the top of the policy page, and potentially interested groups should be notified. It may be helpful to list in the discussion which groups were informed of the proposal. 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. You may Announce your proposal at Wikipedia:Village pump (policy). Try to identify the subcategory of guideline or policy (see {{subcat guideline}}). Editors should respond to proposals in a way that helps 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 remember to sign their response. 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:
    • Consensus for guidelines and policies should be reasonably strong, though unanimity is not required.
    • There must be exposure to the community much beyond just the authors of the proposal.
    • Consider the strength of the proposed page:
    • Have major concerns raised during the community discussion been addressed?
    • Does the proposal contradict any existing guidelines or policies?
    • Can the new proposed guideline or policy could be merged into an existing one?
    • Is the proposed guideline or policy, or some part of it, redundant with an existing guideline or policy?
    • A proposal's status is not determined by counting votes. Polling is not a substitute for discussion, nor is a poll's numerical outcome tantamount to consensus.
    • If consensus for broad community support has not developed after a reasonable time period, the proposal is considered failed. If consensus is neutral or unclear on the issue and unlikely to improve, the proposal has likewise failed.
    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}}, {{How-to}}, or {{Failed}}.
  9. ^ The process for demotion is similar to promotion. A talk page discussion is typically started, the {{underdiscussion|status|Discussion Title}} template is added to the top of the project page, and community input is solicited. After a reasonable amount of time for comments, an independent editor should close the discussion and evaluate the consensus.
  10. ^ If wider input on a proposed change is desired, it may be useful to mark the section with the tag {{underdiscussion|section|talk=Discussion Title}}. (If the proposal relates to a single statement, use {{underdiscussion-inline|Discussion Title}} immediately after it.)