Wikipedia talk:Avoid instruction creep

From Wikipedia, the free encyclopedia

Would it be okay to redirect this page to Wikipedia:Instruction creep, or vice versa? --Folajimi 10:22, 15 June 2006 (UTC)

Original text is from m:Instruction creep, which has been around since July 2004. Davodd 07:05, 3 August 2006 (UTC)

1 Avoid instruction creep...an example of instruction creep?
2 Wikipedians who have used "instruction creep"
3 Suggest change to essay
4 Clarity
5 Example?
6 Is this a guideline?
7 Examples of what is and is not instruction creep
- 7.1 Paragraph from WP:CSD
- 7.2 Step added to Wikipedia:Deletion process
- 7.3 Instruction creep at meta:Instruction creep
- 7.4 Wikipedia:Centralized_discussion/Template_log
8 I'd vote for a total ban on new rulecruft
9 Wow. Pretty harsh.
10 Upgraded to a guideline again...
11 Kudzu image on meta
12 My changes
- 12.1 Protection
13 Should we amend this page to apply to guidelines?
14 Back to basics
15 Soft redirect
16 Obviously policy
17 Added Iron Law of Oligarchy to see also
18 Image
19 This is retarded
20 Instruction creep can be good, bad, or good and bad at the same time
21 Avoid ignoring instructions
22 I read instructions
23 Brief survey of instruction creep in Wikipedia
24 POV in section heading
25 Another Brief Survey Of Creep
26 Irony (Morisettan or otherwise)

[edit] Avoid instruction creep...an example of instruction creep?

Page Title: "Avoid instruction creep" From the top of the page:"This page is a proposed Wikipedia policy, guideline, or process." Further down: "All new policies should be regarded as instruction creep until firmly proven otherwise."

So... Isn't this page an example of itself? Isn't it just saying, "Gee, there are getting to be too many stupid rules, processes, and procedures here on Wikipedia...It would be better if everyone were supposed to avoid making new rules. I know! I'll propose a new rule that says no more new rules!!! Yeah!!! That'll work!!!" 14:05, 4 August 2006 (UTC)

There is an irony, yes. But this is not a new concept in wiki [1]. Davodd 17:02, 4 August 2006 (UTC)

Avoid instruction creep has been a catch-phrase for a while. Personally, I think this should just be an essay. That would avoid the irony. -- Donald Albury^(Talk) 17:49, 4 August 2006 (UTC)

[edit] Wikipedians who have used "instruction creep"

for the full list, see: Search: "Instruction Creep"

The following editors have referenced instruction creep during discussions on Wikipedia. (This list is not meant as an implied endorsement, just as an example of the wide use of this wiki policy.):

Wikipage inclusion

[edit] Suggest change to essay

I suggest this be changed to an essay, as it doesn't actually recommend any particular course of action or create any new requirements. It rather provides a viewpoint. Deco 22:07, 4 August 2006 (UTC)

Ayup! -- Donald Albury^(Talk) 23:21, 4 August 2006 (UTC)

[edit] Clarity

I think I get the second paragraph, but even on multiple rereadings I can't decipher this sentence:

What's more, many bureaucracies also arise with the deliberate intent, as alternatives to regulations; this is almost always noticed by the other side, and tends to antagonize.

Can anyone clarify? ENeville 16:08, 2 September 2006 (UTC)

[edit] Example?

This page could use a general example of the practice it's referring to. Do people post "do not edit this article except in the following ways" messages on article talk pages? That's my best guess at what this is referring to, but I'm not really sure. --Masamage 08:30, 12 October 2006 (UTC)

[edit] Is this a guideline?

So, is this a guideline or considered as a guideline or a proposed guideline? Based on the discussion so far I don't see consensus, and you can count me out too. I agree that it sounds more like an essay. -- Steve Hart 05:11, 6 December 2006 (UTC)

The page originates from meta (m:instruction creep), was written in 2004 and has been a guiding principle since before it was written. There appears to be some confusion here about what a guideline is (see WP:POL) and how they are made (see WP:PPP). Specifically, Steve seems to allude that there is a formal process that needs to be followed to make a guideline - but we do not in fact have such a process. We should ask ourselves whether this page is (1) actionable and (2) consensual. The first is obvious, as it specifies a course of action. The second is visible all over the wiki where we, indeed, avoid instruction creep. Note that the talk page lists a total of 43 users who concur. The counterquestion is, can you find me anyone who thinks we should use instruction creep, or bureaucratic instructions for the sake of covering every possible angle? "It sounds like an essay" doesn't really mean anything. (Radiant) 12:28, 7 December 2006 (UTC)
- "Instruction creep" is too vague a terminology to possibly be of any use as a guideline, and if it is indeed a guideline, we need to start rolling back policies that have been "creeping" by some measure. This should not be considered a guideline. --badlydrawnjeff talk 13:07, 7 December 2006 (UTC)
  - That's akin to saying we should remove WP:CIV because some people have been uncivil. Please point out policies that have been "creeping". (Radiant) 13:24, 7 December 2006 (UTC)
    - It's not analogous at all. We want to avoid incivility, but we've shown no record of actually wanting to reduce so-called "instruction creep" as a community. Our CSD, AIV, DRV pages have all "suffered" from instruction creep relatively recently, and all for the better. If we "avoided" it, we'd be worse off. --badlydrawnjeff talk 13:32, 7 December 2006 (UTC)
      - You appear to misunderstand what "instruction creep" is. It is not simply the writing of instructions; it is the writing of instructions that are needlessly complex, overly bureaucratic, or that solve no actual problem. An example of instruction creep would be anything written in legalese. (Radiant) 13:39, 7 December 2006 (UTC)
        
        Given your definition, I actually understand it perfectly well. --badlydrawnjeff talk 13:42, 7 December 2006 (UTC)
        
        Then please do point out what parts of CSD, AIV and/or DRV were recently added that are needlessly copmlex, overly bureaucratic, or that solve no actual problem, and please explain why you consider this to be "for the better". (Radiant) 13:44, 7 December 2006 (UTC)
        
        I suggest looking at the actual policies and seeing how they've evolved. I'm not going to spend the next 30 minutes mapping out every complex, bureaucratic, useless change to these policies, or point out the "creepy" changes that actually improved them. They're plain as day on the policies. The necessity for this to be a guideline is nonexistent, and there's no consensus to make it as such, nor has an effort been made to get consensus for it. --badlydrawnjeff talk 13:51, 7 December 2006 (UTC)
        
        I am fully aware of how those policies evolved, and I note that about a week ago I had to inform you of a monht-old change in DRV that you were unaware of. So it would seem that you're merely handwaving. The long list of users above is a good indication of the consensus behind the principle here, as are the age of this page and the length of time it stood undisputed, and even you appear to be in agreement that changes that are bureaucratic or legalistic are to be avoided. It's a simple corollary of WP:NOT a bureaucracy, and has proven a useful meme. (Radiant) 14:01, 7 December 2006 (UTC)
        
        So you're aware of how they evolved, and yet accuse me of handwaving. There's no consensus for this to be a guideline, and you've done nothing to demonstrate it. A meta page isn't much of an indication of anything, and practice demonstrates otherwise. No need to make such grand accusations when you certainly know better. --badlydrawnjeff talk 14:06, 7 December 2006 (UTC)
        
        Alleging to something and then, when asked for specifics, refusing to provide any and stating it speaks for itself, is handwaving. That's not a grand accusation, that's a simple statement of fact. (Radiant) 14:12, 7 December 2006 (UTC)
        
        Then, please, stop handwaving and begin demonstrating where the consensus is and how WP:CREEP is common practice. I've given you specifics on three policies/guidelines/processes that have encountered creep recently, simple statement of fact. So where's your consensus? Where's the common practice in regards to policy and process? --badlydrawnjeff talk 14:14, 7 December 2006 (UTC)
        
        "Because I said so" isn't a "simple statement of fact" no matter how many times you rephrase. You could try offering, I dunno, actual simple statements of facts, instead. --Calton | Talk 14:29, 7 December 2006 (UTC)
        
        Already have, so thanks for playing! --badlydrawnjeff talk 14:33, 7 December 2006 (UTC)
You haven't given any specifics. (Radiant) 14:20, 7 December 2006 (UTC)
- Sure I have. I've directed you to the histories of three policies/guidelines/processes. Choose your own adventure. Meanwhile, you've made a series of claims that this is widely linked (false), that avoiding creep is common practice (false), that you have consensus (not evident), and made false claims about my own opinions on the matter. So let's get some fixes from you first before you continue with your line of reasoning, eh? I'll keep this watchlisted and wait patiently for them. --badlydrawnjeff talk 14:33, 7 December 2006 (UTC)
  - Your assumptions are incorrect - Special:Whatlinkshere/Wikipedia:Avoid_instruction_creep makes it clear that this is widely linked, as well as common practice. (Radiant) 14:43, 7 December 2006 (UTC)
    - Less than 50 incoming isn't "Widely linked" at all, and actual practice at the policy pages demonstrates otherwise. --badlydrawnjeff talk 15:22, 7 December 2006 (UTC)

Demoted to "proposed" status until there is wider support. ≈ jossi ≈ (talk) 15:43, 7 December 2006 (UTC)

For what it is worth, though I think the proposed guideline gets misused, I think it is an important point and should be a guideline. Let's rewrite it though, and add examples... Carcharoth 15:49, 7 December 2006 (UTC)

I'm glad to see some discussion. My concern is both how this became a guideline despite little discussion and no consensus (as I outlined on Village Pump) and the language of the current version. I find it (as I wrote on VP) unspecified and sort of saying that our policies and guidelines aren't that important. I know I can't support this in its current form. I think the problem with Wikipedia procedures has more to do with language, that is, if you can actually find what you need in the first place. But the answer isn't, in my opinion, fewer procedures first and foremost, but simpler and more open-ended ones. -- Steve Hart 18:16, 7 December 2006 (UTC)

I agree with Carcharoth. I do think the core principle is a good one, and there should be something here that's a guideline. However, the current writeup does seem a bit essay-ish ("insidious disease", "tends to antagonize others", etc.). Also per Carcharoth's and Badlydrawnjeff's comments, if the principle is being overused, if editors are misinterpreting "simplification is good" as anything remotely like "simplification trumps substantial improvements to policy", then the writeup should try to head off this misuse. --Interiot 20:36, 7 December 2006 (UTC)

[edit] Examples of what is and is not instruction creep

OK. Here are some examples, that will hopefully avoid the silly back-and-forth that Radiant and Jeff got involved in above! Please add your own, and discuss below. Carcharoth 15:28, 7 December 2006 (UTC)

[edit] Paragraph from WP:CSD

CSD reversion of an explanation - 13 October 2006

The above diff introduces one set of edits and reverts on a particular paragraph at CSD. Here are three different versions of that paragraph:

- (1)"Note that administrators should always verify the legitimacy of a speedy deletion candidate before taking action. It is the administrator's responsibility to make sure that speedy deletion tags are accurate." (version before 13/10/2006)
- (2) "Note that administrators should always verify the legitimacy of a speedy deletion candidate before taking action. Verification methods include: reading the page, the talk page (if any), the page history, the page log and checking 'What links here'. It is the administrator's responsibility to make sure that speedy deletion tags are accurate." (13/10/2006)
- (3)"Administrators must verify the legitimacy of a speedy deletion candidate by checking the history of a page before deleting it." (current version - 07/12/2006)

This change I made did not survive, so maybe it was instruction creep. Can the instructions I attempted to provide be found elsewhere? If they can, can someone please point them out. Carcharoth 15:28, 7 December 2006 (UTC)

[edit] Step added to Wikipedia:Deletion process

deletion process stage added (13/10/2006)

This was the addition of a logical step that was missing. Without this step, there is the danger that inexperienced admins would blindly follow process and when "clearing up a CSD backlog", go to Wikipedia:Deletion process for 'instructions' and then follow the first instruction, which was "delete", and is now changed to "verify". This change, unlike the one given above, has survived, so maybe this means it isn't instruction creep. Carcharoth 15:28, 7 December 2006 (UTC)

[edit] Instruction creep at meta:Instruction creep

David Gerard returns the meta page to a "less instruction-crept version". Is this a good example of instruction creep being tidied up? Carcharoth 15:28, 7 December 2006 (UTC)

[edit] Wikipedia:Centralized_discussion/Template_log

It's a duplicate of the page history; people are supposed to add their changes here manually, in addition to the automatically-generated history. A textbook example of superfluous bureucracy. (Radiant) 14:31, 18 December 2006 (UTC)

I agree this is a good example of unecessary bureaucracy. Noting the change in the edit history, and then updating Wikipedia:Centralized_discussion/Conclusions would seem to be all that is needed. Carcharoth 16:20, 28 December 2006 (UTC)

[edit] I'd vote for a total ban on new rulecruft

I HATE all the new "wikipedia is not for postboxes" rules that seem to be springing up. It's awful. Let's get back to basics, if it's verifiable, well sourced and factual, let's keep it. Trollderella 17:19, 8 December 2006 (UTC)

And what exactly does that have to do with instruction creep? (Radiant) 17:21, 8 December 2006 (UTC)
With respect, second that, I'm confused to how this is applicable. Please clarify. Could you define "rulecruft" and define how it applies here. Navou ^talk 22:03, 17 December 2006 (UTC)

[edit] Wow. Pretty harsh.

The article reads pretty aggressively towards good-faith people. (E.g., calling it an "insidious disease".) I think it needs to be toned down a couple of notches. DroEsperanto 15:29, 28 December 2006 (UTC)

Feel free to do so. As they say, {{sofixit}}. >Radiant< 15:38, 28 December 2006 (UTC)

Okay. Still, after reading the article, I still don't get where instruction creep would come into the Wikipedia setting. By "page instructions" does it mean Wikipedia policy like for nominating an article for FA, or does it mean instructions for how to do something in an article? DroEsperanto 16:00, 28 December 2006 (UTC)

It refers to unnecessary instructions. For instance, if you want a page merged, you can either do that yourself or propose and discuss. Instruction creep would be "every merger must be noted on the merging noticeboard, kept there for at least 48 (forty-eight) hours, and acquire the assent of at least three (3) editors of good standing (meaning not having been blocked within the last fourteen (14) days and having over a thousand (1000) edits), after which it passes to the next stage of process where it requires 75% support in a vote with a quorum of twelve (12) people lasting for 8 (eight) days". I'm only slightly exaggerating; people can and do propose such bureaucratic measures. >Radiant< 16:14, 28 December 2006 (UTC)

[edit] Upgraded to a guideline again...

...so what changed? --badlydrawnjeff talk 14:17, 2 January 2007 (UTC)

The wording, and the fact that several people reaffirmed the principle of the page. >Radiant< 14:23, 2 January 2007 (UTC)
- And several people did the opposite. I see nothing since the initial discussion to suggest that this has gone from proposal to guideline. --badlydrawnjeff talk 14:44, 2 January 2007 (UTC)

[edit] Kudzu image on meta

I'm adding the Kudzu image that's on the sister page on meta to this page, guidelines are much better with pictures. If this is controversial discuss/revert whatever, but I don't think it will be. --Matthew 22:32, 17 January 2007 (UTC)

Took me a little while to get it, but I now see its relevance. Picaroon 01:17, 23 January 2007 (UTC)

[edit] My changes

I just made some changes. None are very major, but they add up to a pretty substantial reworking. This included removing the list of guidelines, seeing as it is both somewhat counterproductive to the point of the page and since Jeff has marked its status down to proposed. The Einstein quote is a nice addition if I do say so myself - it narrowly edged out a different one from Confucius. Discussion welcome. Picaroon 01:17, 23 January 2007 (UTC)

Jeff is wrong. This page dates from 2004 and marks long-standing practice. It is in no way whatsoever a proposal. >Radiant< 16:52, 25 January 2007 (UTC)
- No, I'm correct. Meta is meta. --badlydrawnjeff talk 16:58, 25 January 2007 (UTC)
  - I'd agree with that statement if it were a language-specific page being moved to meta, but not vice-versa. Pages on Meta should theoretically apply to all Wikipedias, including en. I'm not sure how its origin on Meta somehow makes it less applicable to the English Wikipedia. Out of curiosity, if the page had been here on en since 2004, would that make a difference? SuperMachine 17:22, 25 January 2007 (UTC)
    - Yes, it would. It would have had years of experience specific to this project, and have wider support than what's indicated here. Many of the points brought up back in December have either failed to be addressed or outright ignored, and no efforts have been made to gain consensus for this to be a guideline here. --badlydrawnjeff talk 17:31, 25 January 2007 (UTC)
      - That is incorrect. Since it came from Meta it definitely applies to the English Wikipedia. There was a brief discussion last year about whether people actually agree to this principle, and the response was that yes, they were. Unless you are able to find people who think instruction creep is a good thing? >Radiant< 09:24, 26 January 2007 (UTC)
        
        I don't think it's a bad thing. Considering the amount of creep we deal with in our processes and policies, it seems like no one else cares, either. --badlydrawnjeff talk 12:26, 26 January 2007 (UTC)
        
        Please point out evidence for those unsubstantiated allegations? The only thing you've so far pointed out is that you like instruction creep and that you believe that you can therefore deprecate a long-standing guideline. Ironically, there are no instructions that allow you to do so. >Radiant< 12:58, 26 January 2007 (UTC)
        
        For one, it's not a "long-standing guideline." For two, check above. There's a short list, and plenty more if you can be bothered to actually see how any of our processes have evolved, from CSD to AfD to V and so forth. Take a tiny bit of effort, please, and stop being tendentious. --badlydrawnjeff talk 13:14, 26 January 2007 (UTC)

Dear BadlyRaddrawniantjeff!,

Wikipedia:Requests for page protection? Or are you guys going to start talking with (instead of against) each other?

--Francis Schonken 17:37, 25 January 2007 (UTC)

I'd like to hear an actual argument against this guideline; so far the only thing we have is meta-arguments. Is there anyone here who thinks instruction creep is good? If not, what exactly are we talking about? At any rate, this is not a proposal, for that term implies it would be something new, when in fact this page has been here for a long time. >Radiant< 09:24, 26 January 2007 (UTC)
- I've given you actual arguments, you've, as always, either ignored them or dismissed them without a thought. We don't avoid instruction creep, so this doesn't reflect current practice, and there's no evidence that this has wide acceptance, as noted above. You cannot simply force your way on this and expect everyone to fall in line. --badlydrawnjeff talk 12:26, 26 January 2007 (UTC)
  - As usual you haven't given arguments, but some handwaving, and as usual you are contemptuous and insulting to other people. Guidelines don't force anyone to fall in line, since as you should know they aren't binding. We do discourage instruction creep; there are probably a few instances where the instructions have crept anyway (although I note you have so far failed to point out any) but that doesn't mean we don't discourage it. Similarly, we discourage page protection, regardless of the fact that some pages are protected anyway. >Radiant< 12:58, 26 January 2007 (UTC)
    - Ah, yes, the old "handwaving" standby, perfect for when there's no other argument. How about you stop dismissing my arguments without thinking and actually build consensus? --badlydrawnjeff talk 13:14, 26 January 2007 (UTC)
      - You are, I hope, aware that ad hominem is a fallacy? How about you quit making snide remarks and give actual arguments supported by actual evidence? >Radiant< 13:28, 26 January 2007 (UTC)
        
        PS: note that also the Argumentum ad Metam can in certain circumstances be a logical fallacy, e.g.: "We need a project namespace page in Wikipedia stating clearly that friends of gays should not be allowed to edit articles: there is such article at Meta, where it is uncontested for several years now." Logical fallacy, because it is nowhere said that all of meta's humor pages should be copied in Wikipedia's project namespace. There isn't even a rule that all other long-standing pages from meta should have a similar page in Wikipedia's project namespace.
        Frankly, I couldn't care less whether Wikipedia:Avoid instruction creep is a policy, a guideline, an essay, or a soft redirect to the similar page at Meta. I have a problem though with Radiant continuing the revert war after having requested the page protection at Wikipedia:Requests for page protection (hoping to avoid the effect known as Wikipedia:The Wrong Version presumably). --Francis Schonken 13:31, 26 January 2007 (UTC)
        
        Gaming the system, what a shocker. Anyway, a soft redirect is something I didn't consider, and something I fully support and endorse. --badlydrawnjeff talk 14:49, 26 January 2007 (UTC)
Silly argument. Perhaps we should have a new policy on editing policies about policy? Oh, wait, that would be instruction creep. Jeff, what is your substantive dispute with the idea that instruction creep should be resisted? Note that instruction creep is in respect of prescriptive instructions, not informative meta-discussion, which is always fine. Guy (Help!) 13:53, 26 January 2007 (UTC)
- Because instruction creep isn't avoided, per discussion above, and because "avoiding" instruction creep is not always best practice, depending on circumstances. We do not generally frown upon such "creep," and partake in it in our general processes regularly. Furthermore, there is no evidence that there is wide acceptance of this, and the appearance is that Radiant believes he's above consensus building on the issue. That's not how we operate here. --badlydrawnjeff talk 14:49, 26 January 2007 (UTC)

Please give an example where instruction creep is good. That is, the addition of prescriptive policy other than to solve a pressing problem. Guy (Help!) 17:52, 26 January 2007 (UTC)

Would you say the evolution of WP:BLP was a "good" example? I would have responded sooner, I didn't catch it. --badlydrawnjeff talk 14:45, 1 February 2007 (UTC)

My view, as it was requested, is that this guideline can be abused (sometimes more instructions are good and needed, and reverting people with the cry of WP:CREEP is bad), but the guideline is still needed. And it should be a guideline, and should be discussed, rather than demoted to a proposed guideline. I believe this guideline does have wide acceptance, it is just precisely what people mean by instruction creep, and where to draw the line, that seems to be disputed. We need to discuss and give actual examples, preferably on a subpage to avoid accusations of, er, instruction creep. See the examples section I started above. Carcharoth 14:45, 26 January 2007 (UTC)
- As the promotion was never discussed, shouldn't that have been the first step? Meanwhile, your examples above are perfect examples as to how we do not always avoid instruction creep, thus my point. --badlydrawnjeff talk 14:49, 26 January 2007 (UTC)
  - You should be discussing the page content, rather than the tag (and also, you should be making actual arguments instead of ad hominem fallacies). There is no such thing as "promoting" pages (indeed, please do point out any policy or guideline that implies you can "promote" pages). >Radiant< 15:15, 26 January 2007 (UTC)
    - Sorry, Radiant, you're diverting focus of the discussion too, for a trivial linguistic issue you did not seem to have any trouble understanding here. --Francis Schonken 15:32, 26 January 2007 (UTC)
Not every piece of text that describes current practice needs to be tagged as a guideline or policy. This simply doesn't have enough actionable content to warrant mixing it in with other guidelines that are genuinely useful. Christopher Parham (talk) 16:23, 26 January 2007 (UTC)

[edit] Protection

It appears that those who feel there's consensus for this haven't bothered to demonstrate it, and there's no further discussion on this. What's the deal, folks? --badlydrawnjeff talk 14:45, 1 February 2007 (UTC)

We're now going on two weeks. Anyone? --badlydrawnjeff talk 18:55, 7 February 2007 (UTC)

I'll unprotect it now, but will reprotect if you and Radiant start revert-warring again. Picaroon 22:09, 7 February 2007 (UTC)

I won't be touching it anytime in the near future, don't worry. --badlydrawnjeff talk 22:12, 7 February 2007 (UTC)

[edit] Should we amend this page to apply to guidelines?

{{editprotected}} Until the recent kerfuffle, I hadn't noticed that this page doesn't technically apply to guidelines, only to "page instructions" and "new policies." Should we amend the relevant section as follows?

Page instructions may have to be pruned at times. Feel free to remove excessive requirements as you see fit. All new policies and guidelines should be regarded as instruction creep unless it can be proved they will actually be helpful.

(The bold text above indicates the proposed addition)

Pro: My understanding is that the primary reason the page doesn't discuss guidelines is that it was largely taken from Meta, and Meta doesn't have guidelines. The spirit of this page would seem to support limiting guidelines as well. Given that guidelines are actionable instructions to editors, they arguably should be guided by the spirit of WP:CREEP at least as much as "page instructions."

Con: On the other hand, leaving guidelines out of CREEP does have the advantage of eliminating the logical contradiction. If CREEP doesn't present an obstacle to guideline proliferation, then it is logically incorrect to argue that CREEP counsels against its own adoption. What do people think? Thanks, TheronJ 19:34, 26 January 2007 (UTC)

Instruction creep for instruction creep! Or something. You're not wrong, though, it probably should be amended. --badlydrawnjeff talk 20:15, 26 January 2007 (UTC)

Ha. Kerfuffle... Anyways, I've always thought of it as referring too guidelines too - only now do I see that those aren't mentioned. Your proposed addition seems reasonable enough. In my view, its not so much a new idea as it is a clarification. Nevertheless, too much clarification will make this page large, complicated, and an example of instruction creep - which, like you said, is something that would make it look just plain silly. None of the three of us seem to be admins, so I've added {{editprotected}}. Picaroon 20:38, 26 January 2007 (UTC)

Ok, done. On a side note, nothing is really changing... only the language to reflect the intent and the actual usage... so it's not really "creep". :) ---J.S (T/C/WRE) 21:06, 26 January 2007 (UTC)

[edit] Back to basics

Is this a guideline?
If yes, does it reflect current practice? I don't believe it does, as demonstrated above.
If yes, is there consensus? I don't believe there is, as demonstrated above. Certainly, no one has demonstrated as such. The closest point made is its existence on meta, which doesn't register here.

So if a page does not reflect current practice, and lacks consensus, how is it a guideline? Can anyone who prefers this explain as such? --badlydrawnjeff talk 15:40, 9 February 2007 (UTC)

Yes, it's common practice, as evidenced by the fact that whenever someone makes an overly-complex, bureaucratic, or unnecessary proposal, other people will object to that on grounds of instruction creep, and that such proposals have a strong tendency to be rejected on those grounds. >Radiant< 15:46, 9 February 2007 (UTC)
- But we don't avoid it, as demonstrated above. Some people respond to vandalism pages per WP:DENY, it doesn't make that common practice, either. It also lacks consensus - it needs both. --badlydrawnjeff talk 15:56, 9 February 2007 (UTC)
  - We do avoid it (although admittedly not always, but then there's extremely little that we always follow). This is demonstrated by several recent policy rewrites/simplifications, and by the fact that we don't stick tightly to procedures anywhere on the wiki, and by the fact that overly-complex, bureaucratic or unnecessary proposals are rejected. >Radiant< 16:10, 9 February 2007 (UTC)
    - Proof of any of that being true? --badlydrawnjeff talk 16:13, 9 February 2007 (UTC)
      - Easy enough. (1) several recent policy rewrites/simplifications, such as Wikipedia:Blocking policy/Simplified, Wikipedia:Attribution, Wikipedia:Centralized discussion/Template log; (2) we don't stick tightly to procedures, as shown by any number of early closures on AFD/MFD/RFA/RM; (3) overly-complex, bureaucratic or unnecessary proposals are rejected, such as Wikipedia:BLP Admin, Wikipedia:Community approval of new articles, Wikipedia:Consensus polling. >Radiant< 16:30, 9 February 2007 (UTC)
        
        So what about the expansions of policies and guidelines as cited above. Did those not happen? As for number 2, the AfD and MfD ones in particular are always controversial, and do not help your argument one bit. As for #3, that's not in support of WP:CREEP anyway. They're not rejected because they creep anything, but because they're poor proposals. The newer policies that have been approved can certainly have some bureaucracy and be "creep"y, see above. Also, consensus? --badlydrawnjeff talk 16:49, 9 February 2007 (UTC)
        
        Well, I'd hate to sound like little echo, but do you have proof of any of that being true? First, of course, expansions of p/g happen, but it does not follow that every expansion is creep. Second, at present the MFD page contains seven early closings, none of which appear controversial, so your claim that they are "always controversial" is obviously false. And third, your last argument is a straw man, since any CREEPy proposal is by definition a poor proposal. Please point out any proposals that were adopted despite being instruction creep. >Radiant< 14:13, 12 February 2007 (UTC)
        
        Proof of what being true? Second, I see seven controversial closes there. Not false at all - quite true, in fact. Third, that's simply your opinion and not based on anything other than that. Please see above for actual examples. And I'll note that you still haven't demonstrated consensus. --badlydrawnjeff talk 14:43, 12 February 2007 (UTC)
Proof of it being controversial? Your apparent dislike of early closure doesn't make them controversial. If you actually believe them to be controversial, you should take them to deletion review; that's what it's there for. I suspect we both already know the outcome of such a review, though, which indicates that there is in fact no controversy. >Radiant< 10:57, 13 February 2007 (UTC)
- Incorrect. --badlydrawnjeff talk 13:14, 13 February 2007 (UTC)
  - I don't quite follow you. Do you mean that (a) your apparent dislike of early closure does make them controversial, (b) controversial closes should not be taken to deletion review, (c) if any of these seven would be taken to DRV, the outcome would not be clear-cut, or (d) something else (please specify). >Radiant< 13:27, 13 February 2007 (UTC)
    - The third. I have had positive outcomes in challenging early closes in the past, as have others. My lack of time or energy to pursue them lately has no bearing on the matter - they are controversial by definition. --badlydrawnjeff talk 13:41, 13 February 2007 (UTC)
    - By the way, any luck finding consensus on this page? --badlydrawnjeff talk 13:42, 13 February 2007 (UTC)
      - Wikipedia customs and common practices are, in proper circumstances, policy or guideline. The consensus lies not in the amount of people signifying consent for some tag on this talk page, but in the way this page is cited and acted upon in practice. >Radiant< 10:59, 14 February 2007 (UTC)
        
        So there's no consensus? --badlydrawnjeff talk 12:49, 14 February 2007 (UTC)

Dudes, there's an Arbitration opening on both of you for this particular behavior. I suggest you spend your energy there, or get yourselves a mediator. Generating more content for the evidence phase is probably not in your best interests right now. --Kim Bruning 11:48, 14 February 2007 (UTC)

[edit] Soft redirect

Since consensus doesn't appear to be forthcoming, and the one thing everyone can agree on is that it has a long history at meta, can we simply compromise and go along with the soft redirect, similar to what exists at WP:DICK? --badlydrawnjeff talk 20:52, 13 February 2007 (UTC)

[edit] Obviously policy

Instruction creep is a well known problem in organizations worldwide. Failure to deal with it is slow but certain death (by red-tape strangulation) for an organization. There's no way this is not a policy, anywhere where sane people gather and try to get work done. Marking as such. --Kim Bruning 11:54, 14 February 2007 (UTC)

Obviously, this is not a policy, considering the amount of problems we're having finding consensus for this to be a guideline. I'm still strongly in favor of this being a soft redirect - it seems the most logical. --badlydrawnjeff talk 12:23, 14 February 2007 (UTC)

Are you (seriously) claiming that instruction creep is a Good Thing? --Kim Bruning 12:37, 14 February 2007 (UTC)

I confirm nor deny such a statement. I do, however, seriously claim that we do not "avoid instruction creep" on any sort of regular basis, and that this page does not currently have consensus for a guideline, let alone a policy. --badlydrawnjeff talk 12:49, 14 February 2007 (UTC)

You confirm nor deny? What's this? Do you think that maybe instruction creep is a good thing? Ok, well, I'll listen, I guess... what are the arguments? --Kim Bruning 12:55, 14 February 2007 (UTC)

It's called I have no major opinion on the matter. Obviously, we do it plenty, and sometimes it's favorable and sometimes it isn't. --badlydrawnjeff talk 13:01, 14 February 2007 (UTC)

In general usage, Instruction creep and Function creep are pejorative terms, so I'm a bit surprised at someone claiming them to be favorable. That would be a contradictio in terminis, in the strictest sense. That can't be right. Perhaps we're discussing different things? Can you define your terms? --Kim Bruning 13:47, 14 February 2007 (UTC)

It's a perception due to an irrational fear of bureaucracy. More to the point, we approve of some bureaucracy but not others, as demonstrated above. --badlydrawnjeff talk 13:56, 14 February 2007 (UTC)

Next to WP:NOT a bureaucracy, the following: Actually, I managed to get some free consulting WP:NOT]] a bureaucracy. Do we really need a hundred policy pages saying essentially the same thing? Adding more dead weight to our ruleset simply increases complexity without adding any light to the way we operate. Shouldn't we be able to suggest to people that are interested in Wikipedia that they glance through our policies and guidelion wikipedia governance at one point, and the consultants strongly recommended against a bureaucratic structure. (they were fascinated by the clan culture, but at the same time recommended more "adhocracy" style management, as that works well in web-based organizations). I could have thought of all that myself of course, but you know the story about the (normally) Eur 300/hour consultants and reassuring oneself ;-) --Kim Bruning 14:04, 14 February 2007 (UTC)

The reason this shouldn't be a policy is that it is redundant to two already existing policies, WP:IAR and WP:NOT a bureaucracy. Do we really need a hundred policy pages saying essentially the same thing? Adding more dead weight to our ruleset simply increases complexity without adding any light to the way we operate. Shouldn't we be able to suggest to people that are interested in Wikipedia that they glance through our policies and guidelines? If the set of such pages is bloated with redundant meta-policies, this is not a reasonable thing to do. Christopher Parham (talk) 22:39, 14 February 2007 (UTC)

I am humbled by the irony. (An yet more humbled by your apparent ability to keep a straight face while making that statement ;-) ) --Kim Bruning 22:50, 14 February 2007 (UTC)

This discussion (and the state of our policy set overall) are good examples of the fact that we don't follow this principle, although we ought to do so. Instead we tack a policy or guideline tag onto anything we manage to agree on. As a result, our manual of style is as long as the AP's and our list of rules to observe runs to hundreds of thousands of words. I don't see a value to adding this page to our policy set, especially since if we are actually "not a bureaucracy," the tag at the top of the page shouldn't determine the force carried by the contents. Christopher Parham (talk) 23:09, 14 February 2007 (UTC)

Perfect. Now to actually get everyone to agree on one tactic. ;-) -Kim Bruning 23:50, 14 February 2007 (UTC)

Soft redirect! --badlydrawnjeff talk 01:10, 15 February 2007 (UTC)

A: What, move all our problems to meta? :-P B: Wouldn't that get Britty angry again? I like her, would like to stay on friendly terms.:-) --Kim Bruning 01:52, 15 February 2007 (UTC)

A) If only! (kidding!) B) Who? --badlydrawnjeff talk 02:28, 15 February 2007 (UTC)

Chris - while I fully agree that we have way too many guidelines, you're using that as an argument against the very page that recommends against making more of them. To reduce our guideline complexity, a better approach would be to look over CAT:PRO and see which of them can be added to existing pages (I tend to recommend that a lot), or look over CAT:G for items to merge. I've started a list here (please comment); it seems we could roughly halve our current policy set through some effective merging, although I should note that the community has rather strongly objected to such merges in the past. >Radiant< 10:12, 15 February 2007 (UTC)
- If this were "the very page that recommends against making more of them," it would be a good guideline. But it is in fact the third page to recommend against making more of them (on en.wp alone). Two are already policy. WP:NOT: "Instruction creep should be avoided." WP:IAR: Less explicit, but if people are free to ignore instruction creep, why implement it? Everything here that is actionable is redundant to already existing policies. Christopher Parham (talk) 16:53, 15 February 2007 (UTC)

I think you have it backward. Existing policies grew out of Avoid Construction Creep; which has been around as a general concept implemented here since 2001 when this project broke off of Nupedia as an antithesis of it's controlled, editorial board concept. The whole idea of WP is to make it as free of bureaucracy as possible to keep an open community ... open. The "avoid construction creep" concept was just so obvious to most of us in the first few years, that no one bothered to write it down until just recently. Davodd 17:45, 15 February 2007 (UTC)

I don't really see what this has to do with what I said. Order of origination is irrelevant, the question is one of redundancy. Christopher Parham (talk) 20:51, 15 February 2007 (UTC)

Jeff - I don't think that moving our problems to meta is really resolving anything. I suppose we should simply tell people to look at WP:NOT if they're looking for a related policy. >Radiant< 10:12, 15 February 2007 (UTC)
- This assumes there's a problem to begin with? Why not simply a redirect to WP:NOT, then? --badlydrawnjeff talk 21:03, 15 February 2007 (UTC)

[edit] Added Iron Law of Oligarchy to see also

I added Iron Law of Oligarchy to "see also", Since:

I have not entirely thought through this edit, and since
I am not quite sure how long my edit will actually stay on Wikipedia:Avoid instruction creep

I mention it here. Travb (talk) 02:21, 2 March 2007 (UTC)

I think its a good link, and, apparently, so did someone else, because it was in there for months until it was removed on Feb 15. But you're gonna have to work on the capitalization. ;) Picaroon 02:32, 2 March 2007 (UTC)

[edit] Image

I prefer the image of kudzu :) >Radiant< 09:50, 1 May 2007 (UTC)

[edit] This is retarded

this is why I hate people. Seriously. -M^ask? 04:12, 2 May 2007 (UTC)

Exactly. -Rocket000 03:15, 21 September 2007 (UTC)

[edit] Instruction creep can be good, bad, or good and bad at the same time

I'm surprised by the seemingly reflexive and breathtakingly one-sided objections to "instruction creep" expressed above. Nowhere do I see any reliable sources being cited to support the several blanket declarations that instruction creep (or feature creep, another pejorative label for complexity) is, in and of itself, inherently evil.

If complexity were inherently bad, then bacteria would be inherently superior to multicellular organisms. Among the latter, simpler flatworms would be superior to more complex chimpanzees, and the human brain (perhaps the most complex system in the known universe) would be the greatest catastrophe of all time. (It may be, but I'm not about to send mine back.)

In reality, systems of varying complexity occupy different functional niches. Bacteria are better at being bacteria than humans could hope to be; and conversely, no bacteria can do what a human can do. Increasing complexity brings with it a mix of advantages and disadvantages. In general, a complex system is capable of more complex and flexible behaviors than a simple system, assuming the complex system is reasonably well designed. The downside of complexity is that it also creates its own inherent problems; however, the continued survival and evolution of complex systems suggests that in a number of contexts, the benefits of compexity outweigh the costs.

A modern bureaucratic nation such as the United States or Switzerland is vastly more complex than, say, a tribe of hunter gatherers living in the Amazon rain forest. And yet despite how much pleasure First World citizens derive from complaining about their bafflingly complex cultures, not many of the complainers seem inclined to switch to the simpler and therefore presumably superior hunter gatherer lifestyle. The problem there is that it takes a vastly complex culture if one desires a life that isn't nasty, brutish, and short. And whenever simple cultures and complex cultures have directly competed, the simpler cultures lost. In the Clash of Civilizations, instruction creep wins every time.

Wikipedia has grown steadily larger and more complex since its inception, and the more complex it has become, the more popular it has become. Wikipedia's complexity has promoted its comprehensiveness as well as its efficiency and synergy. The fact that Wikipedia's editors are busily documenting every single case that comes up more than once in the course of editing an encyclopedia about everything allows other editors to avoid re-inventing solutions to the same problems. Having all these instructions is good. See, for example, this fantastically complex index:

User:John Broughton/Editor's Index to Wikipedia

With this index, I can quickly retrieve answers to a large fraction of questions that I answer on the Help desk. I am very thankful that the editors who contributed that vast collection of value were not deterred by some irrational fear of complexity. The goal which Wikipedia has set out for itself (to build an encyclopedia about nearly everything using a fantastically diverse self-selected community of volunteers) is inherently complex. There is no possibility that a simple system can accomplish a complex job.

As Jerry Pournelle said (somewhere), "You can never have too many examples." What he meant was that big documents have the chance to be better than small documents, because a big document has a higher probability of containing the answer to the next random question than a small document.

Now, obviously, to minimize the potential costs of complexity we must have efficient tools for managing it. The worst way to manage complexity is to attempt to read it from start to finish in a linear way. In computer science, similar problems arise with large data sets which are inefficient to access linearly. Various indexing schemes (such as hashing and b-trees) allow rapid access to vast amounts of data. Indeed, without such techniques, the computer you are using to read my words could not operate, and computers would tend to get slower rather than faster with each increase in chip complexity.

If instruction creep is inherently bad, why are today's computers with billions

of transistors and larger amounts of code so much better than the simpler computers of 20 years ago? Obviously the computer industry has found ways to make complexity pay off.

There also needs to be a selective mechanism for detecting when instructions have become obsolete. But note, this mechanism must be objective, rather than relying on the opinions of individual editors who themselves do not see the need for a particular instruction. Instead, we must have a way to determine which instructions continue to be valid, and we must keep an accurate count of how often they are used. The most frequently-accessed instructions should be arranged to make them easiest to find. However, no instruction should be removed entirely unless it can be shown to be useful to no one. --Teratornis 11:28, 26 May 2007 (UTC)

This is a Wikipedia Guideline, not an article, reliable sources are not needed. Instruction creep is inherently bad for an orginization such as ours. This is exactly why we have Wikipedia:Ignore all rules as one of the five pillars of Wikipedia. Instruction creep reduces the effectiveness of our model by having responses to situations prejudged, rather then considered on a case by case basis on the aspect of whats best for an encyclopedia instead of what the rules say. -M^ask? 23:20, 28 May 2007 (UTC)

Reliable sources are "needed" in the same sense that they are "needed" to support any sort of claim. If a Wikipedia guideline is based on some testable claim about how the real world works, I want to see the results of someone testing the claim. I'm not just going to take it on faith; instead, I prefer critical thinking. The original basis for WP:RS as it applies to encyclopedic articles was the objectivism of Jimmy Wales: when he reads something on Wikipedia, he wants to know the basis for it. I think it makes sense to apply the same standard to every sort of claim; why should there be a lower standard of objectivity for Wikipedia guidelines? When someone tells me fewer instructions are inherently better than more instructions, I want to know what they are basing that claim on, especially in light of all the real-world examples where a complex system is better than a simple system:

The Library of Congress is better than my personal collection of books.
The United States of America is better than a hunter gatherer tribe.
A personal computer manufactured in 2007 is better than a Commodore 64.
The World Wide Web is better than the information on a single floppy disk.
A human is better than a microbe.
A Boeing 747 is better than a Wright Flyer even though the Boeing 747 is vastly more complex (and requires a mountain of documentation).
Unix is better than DOS because (or even though) Unix has far more commands.
Modern medicine is better than folk medicine or faith healing.
The Wikipedia of 2007 is better than the Wikipedia of 2003 despite being far more complex now.

By "better" I do not mean "better in every way," but "better in most ways" such that lots of people ascribe more value to the complex system than to the competing simple system. Of course complexity has to be well-implemented to be better. The Library of Congress, for example, remains usable despite its immense size because it has a large staff of professional librarians who know how to organize a massive library. A Boeing 747 represents a similar level of refinement, compared to a similarly complex junkyard full of parts. The junkyard is not as useful as a working airplane.

I also agree that if there is some procedure with a number of steps such that anyone following the procedure must perform all the steps serially, then in that case we should try to reduce the number of steps in the procedure to the smallest number which will work. But sometimes that involves adding more instructions to the total, for example by splitting a long general procedure into a number of shorter, more specific subprocedures. The total number of instructions could be larger (due to overlap between the subprocedures), but efficiency for the user has increased because a typical user may only need to perform one subprocedure.

This sort of divide and conquer strategy is the basic tool for managing complexity. For example, adding more RAM to a computer speeds it up rather than slows it down, even though adding more memory creates a more complex problem for the computer's address decoder to decode. The address decoder uses a kind of divide and conquer strategy to make the complex problem simple, and turn the increased complexity of more memory into a useful asset.

The basic rule in life is, it takes more to do more. Wikipedia is trying to do more than just about any other volunteer organization, so Wikipedia needs a vast number of instructions. However, just as with any other complex system, Wikipedia needs tools specifically to help deal with growing complexity. The Library of Congress would not work if everybody just dumped books in it. There have to be some people who specialize in organizing the collection. But the organizers' job is to preserve everybody else's contributions, not to go around burning books they themselves have no use for, just to keep things tidy.

I've answered hundreds of question on the Help desk, and I find answering questions on Wikipedia to be far more enjoyable than the technical support I have done professionally because of Wikipedia's vast stockpile of instructions. Answering questions on Wikipedia is so enjoyable as a result that I do it for recreation. (Given that tech support has one of the highest burnout rates of any tech job, this borders on miraculous.) Most questions on the Help desk reduce to simple lookup problems. In most cases, the written instructions are superior to what most people can compose extemporaneously, and if the written instructions aren't good, we can improve them. With a little knowledge of searching, one can look up answers and link to them faster than one can rewrite them from memory. What Wikipedia has done in terms of its own technical support is an astounding advance in efficiency compared to the way much of the world works, where finding answers to problems tends to be a nightmare. By adding even more instructions to handle more and more cases we can improve Wikipedia still further. This process is, in fact, continuing, regardless of any non-empirical claims that complexity is inherently bad. This doesn't mean that we necessarily have to reduce every problem to canned answers, but we should try to "can" all the repetitive parts, preserving scarce human intelligence for the original aspects of a problem. That's the whole point of having computers, actually, to automate all the repetitive stuff. --Teratornis 00:16, 1 June 2007 (UTC)

Tl,dr. Anyway, instructions can be good or bad or both. Instruction creep is bad. Hence the word, creep. >Radiant< 15:22, 4 June 2007 (UTC)

Hello Taratornis. If I really get down to it I could mention documents by military like Chuck Horner, futurists like Alvin Toffler, management documents, computing textbooks about things such as feature creep, engineering principles like KISS principle , mathematics such as game theory, biology by folks like Robin Dunbar, etc.

However, I think maybe we have some misunderstanding about what "avoid instruction creep" really means, so let's see....

Alright well, the trick to managing and maintaining extremely complex systems is to keep them manageable ;-) That sounds rather obvious when you put it that way, but how do you keep a complex system manageable?

One thing to do is before you start, you should trim away all excess complexity and only leave things in that are really really needed. In short, you try to keep things as simple as possible, else you won't be able to see the forest for the trees. What remains is already more easily manageable.

Now one of the things that happen later on in a complex self-maintaining community like wikipedia is that complexity tends to grow automatically sometimes. This is when people keep making up instructions for small exceptions to existing rules, and then they make up rules for exceptions to those rules, etc.

Before you know it, you're no longer in control of the complex system, but rather, the complex system is in control of you. (Yes, exactly like Soviet Russia. For real, in fact.) This drift back to square one is called instruction creep, and is therefore something you want to avoid.

I haven't actually gone into managing complex systems themselves, I've only just scratched the prerequisites, but that's enough from me for now. To summarize: before you even try to manage a complex system, you try to reduce it to the simplest form possible, and try to keep it there. The reason for this is that you don't want to take on a bigger job than you really have to (it'll probably be complex enough as is).

For continued reading: The main factor to watch for in complex systems is scalability. The main factor for managing large communities is acculturation. Our performance in these two factors taken together determines how well the community operates at any point in time.

--Kim Bruning 18:00, 4 June 2007 (UTC)

Beware of applying truisms from irrelevant or quasi-relevant contexts to Wikipedia. It seems the examples you cite are about archaic top-down hierarchical command-and-control systems, such as the Soviet Union, or the 1960s corporation. What about an organic, bottom-up, self-organizing emergent system like Wikipedia? Ten years ago, probably no one would have believed something like Wikipedia could possibly work at all, let alone become as huge and successful as it is now. Wikipedia is the world's largest do it yourself project. What enables a do it yourself project to work? Instructions. Lots of instructions. Wikipedia relies on having enough instructions to cover every situation that comes up in the course of editing, and this is how we remove guesswork and reduce conflict. The vast scope of Wikipedia means we need a correspondingly vast collection of instructions. There is no problem with managing instructions. We have the FAQ, the Editor's index, search tools like the {{Google custom}} template, and the Help desk where human volunteers answer questions by looking up, citing, and if necessary interpreting the relevant written instructions. In pre-computerized days, of course instructions became unmanageable quickly. That's why people invented computers, to help them organize and manage large collections of information. Check out the Help desk, and notice the density of links in the answers. Many questions are repetitive, because many users run into the same kinds of problems on Wikipedia, and the Help desk relies on having written instructions so the volunteers can keep their answers uniform and avoid wasting time on reinventing wheels. The beauty of instructions on Wikipedia is that they are inherently non-bureaucratic - anybody can edit the instructions! When the instructions for a particular procedure start to get creepy, someone will cry "Shenanigans!" and edit out the unnecessary steps. Over time, we can expect Wikipedia's instructions to become more efficient, more to the point, and a better reflection of what works for the people who actually use the instructions. Wikipedia is not a command-and-control hierarchy where distant bureaucrats manipulate resentful underlings who have no say in the matter. If people don't like a particular procedure on Wikipedia, they either ignore it, or they streamline it. Of course most management gurus will have a negative view of instructions, because they probably never studied instructions that were written by the people who use them. Only the people who use instructions are qualified to write them. Everyone else is merely guessing what is best for other people. In any case, I'm not suggesting a rewrite to WP:CREEP, but I will write a counterpoint essay explaining the above points. --Teratornis (talk) 17:22, 2 May 2008 (UTC)

[edit] Avoid ignoring instructions

While I agree that putting huge levels of red tape in the way is bad, totally ignoring the rules, or selectively ignoring them is the opposite extreme of bad. The rules are often there for a reason, not necessarily always good, but usually for some reason. When people starting taking the idea 'such and such is just red tape' and ignore it, bad things tend to happen down the line. Basically put, laziness is obeying rules should also not be acceptable. Additionally, in not all situations do you want something to be easy because that encourages trigger happy types. I think a prime example of this right now is the deletion process where too often the first step taken by someone is to simply delete it, instead of go through any of the proposed alternatives. With a relatively small number of stock edits, one editor can put several other editors into a binding pressure situation. Derekloffin 17:13, 5 June 2007 (UTC)

Wikipedia doesn't have firm rules, so your thesis is flawed. We routinely bend and break rules because writing the encyclopedia is more important than following da rulez. >Radiant< 11:20, 6 June 2007 (UTC)
- Perhaps so, but that is actually becoming a problem. Routinely ignoring any form of structure leads to issues. Derekloffin 17:06, 6 June 2007 (UTC)
  - Would this be about OTRS + BLP? --Kim Bruning 17:52, 6 June 2007 (UTC)

[edit] I read instructions

When you want to assemble a bike, you read the instructions. When you want to master English, you study English. I believe this article would be more aptly titled, Wikipedia:Anything goes. Instructions safeguard us from chaos, and statements like, "Gratuitous requirements should be removed as soon as they are added." are absolutely worthless in my book. It is like saying pictures of ugly people should not be used on Wikipedia. That isn't instruction creep, no, that is "vague-as-can-be creep". In fact, I found nothing in this article to go on were I looking for instruction on instructions. The only purpose I see such an essay serving is to attempt to add legitimacy to editors who vote and edit in ignorance. (Mind meal 11:44, 4 September 2007 (UTC))

Instruction creep is where people make up superfluous instructions that aren't really needed. This kind of making things up generally just tends to gum up the works.

As to anything goes: well, by now the mediawiki engine has been toughened so much that anything short of actual malice won't really put a dent in it, so it's actually pretty much safe to ignore all rules, more so than ever before. I shan't say that the Titanic is unsinkable, but if you do do something that might hurt the encyclopedia, generally the wiki can be used in a way to ensure near-instant graceful recovery.

On that basis one wonders how many of the current "rules" in the project namespace are really necessary, even now. Hmph, well that's what the Ignore All Rules policy is there for, I guess. --Kim Bruning 12:52, 4 September 2007 (UTC)

Our excess of rules was recently emphasized when it was explained that the Manual of Style is capitalized thus because it is a "quasi-book." Surely we could run a bit leaner? Christopher Parham (talk) 22:29, 4 September 2007 (UTC)

Mind Meal - do you really? Have you read every single policy and guideline before you started contributing to Wikipedia? Do you think it would be beneficial to mandate that? >Radiant< 13:40, 4 September 2007 (UTC)

Studying Wikipedia's instructions is analogous to sharpening an axe. The more time one spends sharpening the axe, the easier it is to chop the wood. Nobody can master all the instructions in a reasonable amount of time, but the less an editor knows the instructions, the more likely that editor is to end up wasting time here, by having his or her contributions deleted. Lots of people come to Wikipedia, get ideas, then plunge ahead and make mistakes. Many of them become quite upset when hours of their work goes poof. Would they have been better off if they had read some instructions? Like, duh. The important thing is not necessarily to learn all the instructions, but to gain the meta-knowledge about the instructions, namely that we have lots of them to take the guesswork out of almost every routine task, and we have efficient tools for finding the instructions a user needs for his or her current problem. Wikipedia is not like a physical organization with a bricks-and-mortar location, where people watch other people and proactively offer guidance. On Wikipedia it's all do it yourself, and do it yourself relies on being able to find, read, and follow written instructions. This is the entire basis for Wikipedia. Of course we should write efficient instructions, but this tends to take care of itself, because the people who use the instructions are free to edit them. When I'm following instructions, if I see something that looks useless, I try to find out why it is there. If the seemingly useless step really has become useless, then I'll seek consensus to remove it. Over time, Wikipedia's instructions really do reflect the accumulated problem-solving know-how of other people who have faced the same problems the next wave of editors will face. And that's what makes Wikipedia so great. Most organizations are not nearly as good at accumulating this kind of bottom-up collective wisdom. --Teratornis (talk) 17:37, 2 May 2008 (UTC)

[edit] Brief survey of instruction creep in Wikipedia

Reading this page, I became curious as to how much instruction creep there is in Wikipedia. My impression was that rules (ie., "policy") and guidelines must be proliferating at a fairly high rate since i believe that when the encyclopedia started there were only afew, like NPOV and NOR, and now there are a large number of policies and guidelines. To try to get a quantitative idea of the rate of proliferation, i did a quick survey, attempting to count the number of rules and guidelines in the past and the number now. In case anyone is interested in the results, i give them below. I want to stress that this is a very preliminary survey, and hastily done (it took me at most 15 minutes). Also, i did not find anywhere near the amont of data on the past that i would have liked. It could be dug up but would be alot more work. By the way, i was surprised at how little increase i found.

Warning: I made a serious methodological error here. See User:Atropos' comment immediately following my results of 20 October. -- La la ooh 23 October 2007

Today (20 oct 2007) I found 47 articles in the category Wikipedia:official policy.
The version of 19:46 7 oct 2006 had 47 articles. No change.

The Wikipedia:List of policies today listed 38 policies.
On 22:17 8 Jan 2006 it listed 40. Decrease of 2. (i counted quite quickly and could be off by two or three).

Guidelines are broken up into subcategories. I looked at two.
The category Category: Wikipedia behavioral guidelines today has 9 pages.
The category page was created June 7 2007 and only has one version, the present one.

Category:Wikipedia editing guidelines today contains 17 pages
On 7 June 2007 it also had 17. No change.

Note that my little survey does not extend very far into the past. Also, the categories and lists may not actually show all of the pages; this depends on whether anyone put the poicy or guideline into the category or list. --La la ooh 20 October 2007

Note that only the second of those is at all valid, as the number of pages in a category is does not change in old revisions. The inclusion of a page in a category is a change made to the page itself, when a page is added to or dropped from a category there is no revision to the category's page. Atropos 05:00, 22 October 2007 (UTC)

I checked this and you're right. I'll have to think of another method. La la ooh 23 October 2007

A reasonably approximate measure of the current level of instruction complexity might be the size of the Editor's index. The Editor's index would not provide much useful historical data, because it is fairly new, and may still be growing due to late additions of instruction pages that are not new. --Teratornis (talk) 18:26, 2 May 2008 (UTC)

[edit] POV in section heading

This article is about "instruction creep". The noun "creep" has a primary meaning of a "slow, gradual, quiet, or stealthy change or movement". However, the section heading "Non-creepy_instructions" uses the adjective "creepy" whose primary meaning is "producing a feeling of unease, repulsion, horror". This clever wording may have been chosen partly for comic effect or to manipulate readers' emotions, but it seems POV. - Neparis 18:26, 6 November 2007 (UTC)

You are using the wrong definition of "creep" in your research, it's based on the verb form, meaning slow, gradual movement: http://en.wiktionary.org/wiki/creep#Verb. For an analogous noun form, try here: Creep (deformation) - Davodd 22:31, 7 November 2007 (UTC)

The primary meaning of adjective "creepy" is completely different from the primary meanings of both noun "creep" and verb "creep". Only adjective "creepy" implies something horrifying, unpleasant, or repulsive. Describing one alternative as "non-creepy" implies the other alternative is "creepy", i.e. that it is something horrifying, unpleasant, or repulsive, which is POV. - Neparis 21:03, 8 November 2007 (UTC)

I don't really agree with this point, for the same reason as Davodd. That said, I was bold and changed it to "Avoiding Instruction Creep". Seems to reflect the content of that section better. - A Silly N00b (Talk) 14:17, 11 November 2007 (UTC)

[edit] Another Brief Survey Of Creep

Inspired by La la ooh above I've looked at the increase of policy and procedure page size since about April 20 (when page size started to be included in edit history). Basically, I compared the current page size to the page size of either the earliest included page size or the page size of the first revert. A quick look at the Five Pillars plus No Original Research and Verifiability revealed that

What Wikipedia Is Not had increased in size from 33065B to 41223B (8158B, 24.6%)
Neutral Point Of View had increased from 34559B to 38726B (4167B, 12.1%)
Copyrights had decreased from 24193B to 24176B (17B, 0.1%)
Etiquette had increased from 13338B to 13678B (340B, 2.5%)
Ignore All Rules had increased 2246B to 2571B (325B, 14.5%)
Verifiability had increased from 8551B to 11721B (4167B, 37.1%)
No Original Research had increased from 17956B to 22275B (4319B, 24.1%)

The grand total comes in at an increase of 20kB, or 15.3% over a little over half a year.

Would anyone be interested in the results if I expanded it to include all the policy and/or guideline pages and made it a bit more rigourous? It looks like it'd be a decent method once the details are nutted out, and the data would at the very least be interesting. - A Silly N00b (Talk) 16:27, 11 November 2007 (UTC)

I'm constantly at odds with bureaucrats/administrators about this each time they throw some half-arsed guideline in my direction and quote only the parts they like. I wouldn't disagree with your research. Gamer Junkie ^{T / C} 23:39, 4 January 2008 (UTC)

The proper response to all this is to, with some regularity, purge policy pages of their accumulated irrelevant cruft, weasel wording, and needless caveats. Either that or protect the lot in a simple and meaningful state. Unfortunately, I'm one of the few 'pedians who does such purges (I've been known to cut WP:CSD in half to make the page clear for a change) but You Can Help! >Radiant< 23:19, 17 January 2008 (UTC)

I suggest starting with policy pages; there are fewer, and they're more important. Please do provide a diff to show which two versions you're comparing (and to let editors see what actually did change). And it would be nice to compare both six months ago and 12 months ago to the current version. Finally, it would be good check that what you're using was a stable version, rather than catching the policy in the middle of an edit war; if necessary, shifting the measuring point by a week or so to get a really stable version seems acceptable to me. -- John Broughton (♫♫) 16:02, 20 January 2008 (UTC)

Before summarily deleting any instructions, I recommend checking the backlinks to see if anyone recently cited the sections in question. That is, before deciding something looks useless, see if anyone is demonstrably using it. Help desk volunteers routinely cite instructions in their answers to questions. A section of an instruction page that is still answering questions should stay. Deleting it will break links in the archived Help desk pages. People do search the Help desk archive to find previous answers to questions, so it would be nice if the old answers could stay non-broken as long as possible. --Teratornis (talk) 18:32, 2 May 2008 (UTC)

[edit] Irony (Morisettan or otherwise)

[2] O:-)

--Kim Bruning (talk) 15:20, 29 May 2008 (UTC)

Yup :-) But from where I stand, this was just an R in BRD. --Kubanczyk (talk) 08:27, 30 May 2008 (UTC)

Hmph. You used the words "no consensus", which a proper BRD-er must never utter. ;-) Nice try though! :-) --Kim Bruning (talk) 13:20, 31 May 2008 (UTC) You're supposed to state the reasons why you disagree with the previous edit. Feel free to do so now, of course. :-)

Gosh, so am I an improper BRD-er then? I guess I am. When it comes to D: I would like this article to be shorter, too. But after the anonymous'es edit, this article contained insufficient details on the reasons for avoiding instruction creep. This just wouldn't work. The purpose of this essay is to be linked from debates and hit the readers so hard, that they abandon guideline creation (or complication) plans on the spot. --Kubanczyk (talk) 19:47, 31 May 2008 (UTC)

Good point. Hmmm, can you sort of meet anonymous in the middle? --Kim Bruning (talk) 22:41, 31 May 2008 (UTC) Whatever you were before, you're a more proper BRD-er now ;-)

Sort of obviously not. Anonymous is nowhere to be found right now... And I'm not meeting them in the middle of nowhere! --Kubanczyk (talk) 23:15, 31 May 2008 (UTC)