Wikipedia:Avoid instruction creep

This is an explanatory essay about the procedural policy regarding policies and guidelines.

This page provides additional information about concepts in the page(s) it supplements. This page is not one of Wikipedia's policies or guidelines as it has not been thoroughly vetted by the community.

Shortcuts

This page in a nutshell: Guidance that is too wordy and tries to cover all the bases and every conceivable outlying case tends to become counterproductive.

Wikipedia policies and guidelines exist to document community norms for all readers, especially those unfamiliar with how Wikipedia operates. It is important that such pages remain readily understandable and in line with community consensus. All edits, especially substantive additions, should be carefully considered. Too much instruction can result in complex pages, which will seldom be read and understood.^[1]^[2]

Development

Like articles, policy and guideline pages can generally be edited by anyone. Often, somebody thinks that such-and-such a point should be addressed, or that more explanation would be helpful, and edits accordingly. Such additions can end up being quite unhelpful. Gradual bloating, if left unchecked, can make a page less and less coherent, less inviting, and less reflective of community consensus, which becomes difficult to gauge when few users are reading and understanding the page. Project pages are meant to be very broad in scope, and thus cannot hope to adequately cover every minute aspect of the issues they deal with.

Prevention

Keeping policies and guidelines to the point is the most effective way to preserve transparency. Substantive additions to policy should generally be rejected unless:

There is an actual problem to solve, and not just a hypothetical or perceived problem.
The proposal if implemented is likely to make a real, positive difference.
All implied requirements have clear consensus.

All instruction should be as clear as possible. Ensure that additions are placed in a logical context, and do not obscure the meaning of surrounding text.

It is usually better for a policy or guideline to be too lax than too strict. Content not clearly prohibited by any policy is still subject to editor discretion. Consensus-building on article talk pages can be undermined by an over-strict policy, as an editor who wants to follow it literally can claim that the issue is already decided.

If you just think that you have good advice for Wikipedians, consider adding it to an essay.

Fixing

Since things can sometimes "creep in" without much scrutiny, even longstanding instructions should be subject to review. The amount of time an instruction has been present does not in itself establish consensus, although one should be cautious about removing a longstanding part of policy.

If an instruction does not make sense or does not seem to describe accepted practice, check the page history to see when it was added and how it may have changed over time. Then check the talk page and talk archive, to see whether there was any related discussion. If you think the instruction lacks community consensus, either make your case on the talk page or boldly remove it, giving your rationale in the edit summary. If you meet with disagreement, discuss the matter further. Those who oppose an outright deletion may still be open to changes.

Misuse

Shortcut

WP:NOTCREEP

"WP:CREEP" is not a substitute for actual arguments. Lengthy instruction can be helpful, if it clearly and accurately represents community consensus.

Source

This page was inspired by the Meta-Wiki concept: m:instruction creep.

External links

Meta-Wiki • Instruction creep

^ Vergano, Dan (3 January 2013). "Study: Wikipedia is driving away newcomers". USA Today. Retrieved 19 November 2014.
^ The Decline of Wikipedia: Even As More People Than Ever Rely on It, Fewer People Create It | MIT Technology Review

[1] Vergano, Dan (3 January 2013). "Study: Wikipedia is driving away newcomers". USA Today. Retrieved 19 November 2014.

[2] The Decline of Wikipedia: Even As More People Than Ever Rely on It, Fewer People Create It | MIT Technology Review

[1]

[2]