| Revision as of 22:42, 10 May 2007 editKevin Murray (talk | contribs)Extended confirmed users14,670 edits Let's try a compromise while we work together to improve this← Previous edit |
Latest revision as of 20:49, 28 January 2022 edit undoEthanGaming7640 (talk | contribs)Extended confirmed users17,055 edits Modifying redirect categories using Capricorn ♑ |
| (79 intermediate revisions by 24 users not shown) |
| Line 1: |
Line 1: |
|
|
#REDIRECT ] |
|
{{guideline|]}} |
|
|
{{disputedpolicy}} |
|
|
|
|
|
|
|
{{Redirect category shell| |
|
|
|
|
|
{{R to project namespace}} |
|
The purpose of this page is to describe how to modify or create a Misplaced Pages ]?. The same process applies to creating guidelines, which are generally less strict or official than policies. The purpose of a written policy or guideline is to record what has evolved in actual practice rather than to be prescriptive to change our behavior. '''Neither policy nor guidelines are created by voting upon them, they are created by ''forming ] through discussion'''''. |
|
|
|
}} |
|
|
|
|
== How to evaluate a policy == |
|
|
1. Evaluate how the process is working at Misplaced Pages and seek feeback from recent participants in the process. Consider whether we are handling this issue well. |
|
|
|
|
|
2. Check ] to see if any relevant policies already exist, or could be modified to include this process. Changes to existing policies/guidelines are generally discussed on the policy talk page, rather than on a new page. |
|
|
|
|
|
3. Observe how the process of handling this issue has evolved and discuss your observations with others. |
|
|
|
|
|
== How to modify a policy == |
|
|
1. To propose modifications of existing policy, use the talk page of that policy. Try to provide some examples of the issue of concern. |
|
|
|
|
|
2. Make changes in small steps. Be bold, but if you are reverted explain your reasoning, and offer good examples and try to find a compromise. |
|
|
|
|
|
3. Work towards establishing ] through further compromise among the editors participating in the discussion. |
|
|
|
|
|
== How to propose a new policy == |
|
|
''See also: ]'' |
|
|
|
|
|
1. Create a new page with a rough draft of your proposal. Try to include: |
|
|
:(a) A statement ''at the top'' explaining what you're proposing. |
|
|
:(b) A brief summary of your proposal. Make sure it's actionable. |
|
|
:(c) An explanation of the reasoning behind the proposal. It generally helps to cite an actual, non-hypothetical problem that your proposal intends to solve. |
|
|
|
|
|
2. Get feedback! |
|
|
:(a) Link any existing discussions related to the proposal to your proposal page. |
|
|
:(b) Advertise your proposal. Suitable places to do so include ] and ]. |
|
|
:(c) Add the {{tl|proposed}} tag to the top of the page. This will add your proposal to ]. It may likewise be useful to link to ]. |
|
|
|
|
|
3. Work towards establishing ] through compromise among the editors participating in the discussion. |
|
|
|
|
|
== Guidelines for creating policies and guidelines == |
|
|
|
|
|
The following general principles were gathered together following the implementation of several policies across the encyclopedia. As you will see from the guidelines themselves, these points are '''guidelines''', not '''rules'''. You know best what will work in your case. |
|
|
|
|
|
# '''Choose policies that have sprung up organically, not imposed from the top down'''. Contributors "in the trenches" can tell when recurring themes and ideas appear across several articles. Look for conventions that are introduced by one user, but are then copied and adopted by other users. These "de facto" policies often prove very workable. Indeed they are already in practice, so making them "official" is more of a formality than a new policy. |
|
|
# '''Leave room for flexibility''' (or: ''']'''). Although a uniformity of style is itself a good thing, it sometimes forces contributors into a straitjacket that they won't like. For example the very flexibility of our ] on allowing all styles of English spelling rather than just the dominant one, has caused it to be a very stable, implementable policy. Although new users often ask if and what the policy is, they tend to accept it pretty quickly once they've been shown the relevant policy page. The same is not true of inflexible policies, which generate the same arguments over and over again. |
|
|
# '''Don't be prescriptive. Devolve responsibility'''. Although it is tempting to try to cover every possible angle that might arise, it is not always possible. Doing so can lead to long complex policies, with loopholes. Very precise rules are things that badly-intentioned users sometimes ''love''. A policy that says "Doing X n times in a day is grounds for a banning" is often unhelpful - trollish users can and will then deliberately do X (n-1) times in a day. Better to write "Doing X is considered bad. If a user continues to do X after being warned that it is inappropriate, users may decide to {report to arb. committee/implement a temp ban/protect page/revert}". The number of "good" users overwhelms the bad - trust the users to sort things in specific cases, the policy just provides the framework. People are smarter than the words on the page will ever be. This is similar to having a judge to implement and interpret laws. |
|
|
# '''Avoid kneejerk reactions'''. Suppose one user does something annoying once. It is then often common practice to add to the boilerplate at the top of the relevant policy page, prohibiting what that user did. This in the past has led to ] that often consider minutiae irrevelant to the broad thrust of the policy. Consider whether it was a one-off, and thus whether it is better to keep that detail on relevant talk pages. |
|
|
# '''Flexibility again'''. Most articles are only monitored by a few people. Debates are generally manageable, and consensus (often unanimous) can be reached. On very popular policy pages, this is not the case. Lots of people monitor these pages. If you cast a change in "either/or" terms you will often get opinion divided down the middle. Thus, if your policy change has to come to some sort of vote (ample discussion '''''always''''' comes first, because ]), use a form of ] rather than ] voting. Layout all the options, and for each option allow the user to say if the proposed solution is acceptable or unacceptable. If you only have two options to list, examine whether all the middle ground possibilities have been included. |
|
|
# '''Check existing policies'''. Consult ]. Keep in mind ]. Also check meta, wardwiki, and meatball for inspiration; these wikis are still being maintained. |
|
|
# '''Consult widely''' - make a special effort to engage potential critics of the new guideline, engage them and get them to help find the middle ground early. (If all else fails, you can use the Bold revert discuss cycle to find these critics) |
|
|
# '''Do not rush''' - you will get there faster if you give the process the time it needs. People may oppose an idea simply because they feel it has not had adequate discussion, and especially if they feel a policy is being ''pushed through'' to circumvent discussion. On the other hand, some amount of friction can always be expected these days. Don't slow down TOO much! |
|
|
# '''Do not call a vote'''. Votes are rarely appropriate for policy debates, and almost never for guidelines. A vote can never ''create'' consensus, instead it may or may not indicate ''existing'' consensus. |
|
|
|
|
|
===Role of examples=== |
|
|
Policies as well as guidelines can benefit from ''examples'': |
|
|
;Guidelines usually contain more examples than Policies : Most Guidelines document the implementation of the general principles of Policies in concrete circumstances: for that reason Guidelines quite naturally contain more examples than Policy pages. Examples can ''change'' (for instance, an article that used to be a good illustration to some guidance, can be turned into a ''disambiguation page'', or the particular example might be moved to a subpage, etc.): while Policies require more consensus to change (they generally have more ''resistance'' to swift change), it should especially be taken care of that the examples on Policy pages require ''stability'' over a long period of time. For example, the ] policy page used to contain names of publications as examples of ''unreliable sources''. These ''examples'' were however moved to a guideline: branding publications as "unreliable" as a policy-level appreciation is far too absolute to be workable. |
|
|
;Role of examples during the creation process of policies and guidelines : During the creation process of policies and guidelines ''examples'' play an important role: these examples can as well be ''positive'' (the policy/guideline attempting to describe how in the past particular issues were successfully handled), as ''negative'' (the policy/guideline attempting to describe how a particular problem can be resolved in the future). As an example of the latter, the ] was instrumental for the development of ]. Another example of how examples keep the development of a guideline checked: ]: new guideline descriptions are cross-referenced to prior ] cases to check whether the new guideline doesn't deviate from Wikipedians' prior assessments, and/or whether the new guidance would in the future be able to resolve problematic situations without recourse to voting. |
|
|
;Choose clear-cut examples : A well-chosen example can often make things clear and understandable far better than long-winded detailed descriptions can. For that reason the selection of the most appropriate examples for guideline and policy pages should not be trivialised: for instance, don't choose examples for which Wikipedians are strongly divided what is the best solution for that example (''unless'', as a "clear example" illustrating why a guideline chooses a "we agree to disagree" approach). Note, for example, the examples used in ]: although the area discussed in that guideline section is highly contentious, the examples are always clear: this helps Wikipedians when writing articles about these delicate topics to assess what phrasing would be acceptable, and how to avoid to go over the top. |
|
|
:Also, use examples relevant to the '']'' you're writing the guidance for. If you're creating guidance specifically for ''article namespace'', it wouldn't be a good idea to use examples from how issues were tackled in ''user talk'' namespace, etc. |
|
|
:Sometimes images can help to create a clear example, see ]. |
|
|
|
|
|
== Policy discussions == |
|
|
|
|
|
The central place to discuss policies is ]. Policy issues also may be formulated and debated on ], at ], on ], and on our ]. The ] offers a ] to <span class="plainlinks"></span> Misplaced Pages related news and announcements, including the locations of policy proposals and discussions. |
|
|
|
|
|
== Difficulty of policy adoption == |
|
|
|
|
|
Wikipedians who wish to create or amend policy should proceed with due regard for the difficulty of the process. Some of the most widely known policy adoptions are: |
|
|
|
|
|
# ] - c. January 2006 |
|
|
# ] - December 2005 |
|
|
# ] - September 2005 |
|
|
# ] for speedy deletion - July 2005 |
|
|
# ] - November 2004 |
|
|
# Creation of the ] and adoption of its initial rules - January 2004 |
|
|
# Widening of the ] criteria - January 2004 |
|
|
# Creation of the ] - April 2003 |
|
|
|
|
|
Numbers 2 and 4-8 of these had sponsorship or support of ]. |
|
|
|
|
|
During this time period, at least 80 proposed policies and proposed policy changes have been ]. |
|
|
|
|
|
] |
|
|
|
|
|
] |
|
|
] |
|
|
] |
|
|
] |
|
|
] |
|