Wikipedia talk:Avoid instruction creep/Archive 1

This is an archive of past discussions on Wikipedia:Avoid instruction creep. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

Image

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

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)

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)

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)

Redirect

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)

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)

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)

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)

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)

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)

Expanding the tips section

I think we should provide more instructions on how people should avoid instruction creep. 24.205.50.170 (talk) 16:58, 10 September 2008 (UTC)

You may be joking, but your joke exploits the inherent contradiction in disparaging instructions on a site that runs on instructions. The only sustainable ways to influence behavior on Wikipedia are to refer to existing instructions (which we call the consensus) or negotiate new instructions (expand the consensus to cover a new case). One method to avoid instruction creep is to document why one is adding new instructions. For example, a volunteer on the Help desk may discover a gap in the existing instructions, when a question comes up that no existing instruction document adequately answers. If the same question comes up repeatedly, then the instruction gap needs to be filled. In that case, the instruction-"creeper" would clearly understand why he or she is adding new instructions. But actually, the instructions are probably not new, because if a question is answerable on the Help desk, it is probably just a clarification, or synthesis, or incrememental extension of existing instructions. We see this in the style guides of the various WikiProjects. Everything in those style guides represents applications of the general guidelines and policies to specific cases that come up repeatedly in articles in particular topic areas. It is more efficient to keep documenting more and more special cases as they arise, rather than require future editors to waste time reinventing those wheels. That is, it takes some work to determine how the general guidelines apply to specific cases, but less work to find and read the previously worked-out determinations. This is analogous to how the legal system works. There is a complex legal code, and over time an even more complex body of case law accumulates. It is pointless to complain about the complexity of law, because the law merely reflects the underlying complexity of society which isn't going away. Instead we have to roll up our sleeves and build tools to deal with the complexity - and we also recognize a legal profession which gets paid to manage that complexity for other people. Wikipedia is the world's biggest encyclopedia and (possibly) the world's biggest collaborative volunteer project. There is no way Wikipedia can be simple, so it is not constructive to pretend Wikipedia can be made simple. On Wikipedia we can have (and do have) users who choose to specialize in helping other users look up instructions. Visit the Help desk and the Village pump to see them in action. Instead of freaking out over our huge instructions, we should marvel at how useful those instructions are for answering the incredible variety of questions on the Help desk quickly and easily. Ultimately, if computers pass the Turing test, then we can build all that understanding of the instructions directly into Wikipedia itself, so we won't need human volunteers to answer questions. Instead users will interact with Wikipedia as naturally as they would interact with an expert Wikipedia user alongside to guide them. But until then, we seem to getting along well enough with human volunteers who don't mind navigating the instructions on behalf of any other users who ask for help. --Teratornis (talk) 21:09, 12 October 2008 (UTC)

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

--21:55, August 4, 2006 (UTC)

How do we know which instructions "are needed"?

I agree with this claim as written:

Instruction creep is where people make up superfluous instructions that aren't really needed.

But how do we know which instructions "are needed"? I can most easily judge which instructions I need, but my needs are only a tiny subset of the collective needs of all Wikipedia users. Wikipedia is extremely large and complex; I do not edit every type of article (for example, lately I have focused on articles about energy, which have their own particular characteristics, and present different kinds of editing problems than, say, articles about religion or popular music etc.). There are many instructions I have internalized by now, so I follow them without really thinking about them. I no longer need those instructions to be in writing, but users who have not learned them yet still need them in writing. On Wikipedia there is no common sense, which means every user's need for instructions differs to some degree. Since we can only write one set of instructions, and we cannot safely assume that every Wikipedia user shares any common background knowledge or way of looking at things, our instructions have to be highly detailed. Probably much of what looks like instruction "creep" to some people is the natural result of other people reacting to misunderstandings of the previously ambiguous instructions, by adding more detail to eliminate plausible but incorrect interpretations of them. As far as how to manage instructions, it is somewhat remarkable that we would be asking this question on Wikipedia, which is after all an information management tool. If Wikipedia cannot figure out how to manage its own internal information that it needs to operate itself, how can Wikipedia imagine it will reach its goal of providing "the sum of human knowledge to every person in the world free of charge"? But not to worry, Wikipedia has fabulous tools for organizing information. To see these tools in action, read the Help desk. The Help desk has many volunteers who are adept at navigating Wikipedia's large internal store of how-to information (as in, how to build and operate Wikipedia). Help desk volunteers answer a huge variety of "How do I...?" questions quickly and efficiently by linking to instructions. Finding the instructions is not difficult, and the Help desk volunteers have written instructions on how to find them. By now, it should be evident that I sneakily answered my own rhetorical question: one way to know which instructions "are needed" is to answer questions on the Help desk. The Help desk offers a glimpse into the problems and questions that actual users are having. The only way to solve these problems is to provide instructions. It's much more efficient to link to already-written instructions, rather than to rewrite them extemporaneously. Thus it's not really a question of whether instructions are going to "creep" - that is inevitable as Wikipedia grows and ever more diverse people join the project. The question is whether we will collaboratively edit one copy of our instructions and then cite that canonical copy, or whether millions of people will continually reinvent the wheels in ad hoc ways, such as working out by trial and error the procedures they should have followed by observing other editors reverting their work. --Teratornis (talk) 20:43, 12 October 2008 (UTC)

Proposed guideline?

I know this is a bitter irony, but has anyone considered proposing that this a guideline? According to the Economist, entries about governance and editorial policies are one of the fastest-growing areas of the site and represent around one-quarter of its content.[3]

Perhaps the guideline could be used to even demote some guidelines.

Also, does anyone explicitly oppose proposing this as a guideline? Tealwisp (talk) 17:35, 14 March 2009 (UTC)

It used to be a guideline back in the early days of WP via the Wikimedia project. No one bothered to write it down since creepism was such an anathema to the spirit of wiki. It was voted out by folks who like to make new rules. - Davodd (talk) 07:24, 16 March 2009 (UTC)

I keeping reading articles about how Jim Wales and other editors such as Mindspillage wax poetic about the early days of wikipedia.[4] travb (talk) 04:55, 5 January 2009 (UTC)

The essay could become inclusive of creep in general, such as in reference to abbreviation, whereby people are voting for the name they associate with an item, for instance, United Kingdom of Great Britain and Ireland becoming UK and United States of America becoming US. It's widely accepted but entirely destructive. Sorry to land this weight on US and UK but as a prime example, pet names are OK in speech but United or States is not unique and certainly not suitable doors to close, are they? If we want to use those words, should we sprechen a different sprak? Should we stomp out peoples preference to use those terms in speech if we agree to use the full name in officialdom? Does the US government, for instance, head their paper as "US" or as "Government of the United States of America"? We should be able to abbreviate our speech without removing all the stuff or we have something to fear. ~ R.T.G 22:36, 31 January 2009 (UTC)

While I appreciate the irony, imo this is a page which probably should have been a guideline all along. The problem was/is actually defining "instruction creep" in such a way that "Avoid instruction creep" becomes a truly meaningful statement which has a wide consensus. PSWG1920 (talk) 16:23, 4 January 2010 (UTC)

Support – The essay should have leapfrogged "guideline" and went straight to "policy" long ago. Truth is, it does not matter what the essay actually says, the title "Avoid instruction creep" is enough to get the point. —Aladdin Sane (talk) 19:26, 4 January 2010 (UTC)
- I agree that this page should be policy, but not regardless of what it says. I don't think the title by itself is enough to explain what exactly should be avoided and why. Nonetheless I'm hopeful that the page is now improved enough to be seriously considered for promotion. PSWG1920 (talk) 18:28, 5 January 2010 (UTC)

IAC begins by stating that this occurs when "stated requirements which don't reflect true community consensus nonetheless appear on official guideline or policy pages." That's a controversial statement that I think renders this essay incapable of becoming a guideline or policy, not least because it contradicts the "consensus" that guidelines and policies do reflect "consensus." I do agree that "consensus" is one of the more problematic things on WP, something that needs fixing (oh no, instruction creep!). I do often wonder how many editors were actually involved (consensus vs. broad consensus). It also seems that policies or guidelines... or even narrow consensus often aren't followed anyway; one single editor or a small minority of editors are capable of getting their way through sheer persistence. That said, I despise the phrase "avoid instruction creep." It seems, insofar as I have seen it used, to be most often cited by editors who don't give a rat's ass about evidence or logical arguments or quality. Instead, what I think merits further consideration is how to increase involvement in evolving guidelines and policies, and improving the guidelines and policies such that a larger percentage of editors read them and think, "I agree: I see the arguments and evidence for these, and they make good sense." The ultimate goal (maybe not for everyone?) should be WP as an RS, but IAC would be a step backwards in terms of that. Шизомби (Sz) (talk) 23:47, 5 January 2010 (UTC)

Regarding WP:CREEP stating that "instruction creep occurs when stated requirements which don't reflect true community consensus nonetheless appear on official guideline or policy pages", it's incontrovertible that this does happen, at least for short periods of time, simply because guideline and policy pages are generally open to being edited by anyone.

As far as your statement: "Instead, what I think merits further consideration is how to increase involvement in evolving guidelines and policies, and improving the guidelines and policies such that a larger percentage of editors read them (emphasis mine) and think, "I agree: I see the arguments and evidence for these, and they make good sense." WP:CREEP supports keeping such pages short and simple so that more users will read and understand them. PSWG1920 (talk) 06:01, 9 January 2010 (UTC)

Support. WP:CREEP is already used/mentioned in WP:NOT which is a POLICY. Skip guideline and make this a policy as it already is. ηoian ‡orever ηew ‡rontiers 06:00, 15 January 2010 (UTC)

I think CREEP got added to NOT without true community consensus. :-} Шизомби (Sz) (talk) 14:05, 15 January 2010 (UTC)

When instruction creep has talk page consensus?

This thread's title probably sounds like an oxymoron, so let me elaborate. On the principle of WP:NOTLAW, what if anything can be done when a clause which doesn't accurately reflect what is commonly accepted or rejected in practice nonetheless has the consensus of editors who participate on the talk page of the guideline or policy in question? There is one obvious answer, but which is strongly discouraged by WP:POINT. PSWG1920 (talk) 17:59, 18 May 2009 (UTC)

I'm not entirely sure what you mean, so let me try to clarify.

If Editors A, B, and C all agree to style guidelines that say to use essay style, but common practice is to use journalistic style, what can be done if only A, B, and C are making the style guidelines? Is that what you're asking? Tealwisp (talk) 04:15, 1 June 2009 (UTC)

Yes, that is what I mean. PSWG1920 (talk) 04:23, 1 June 2009 (UTC)

The "other side" of what?

The intro reads, "many bureaucracies also arise with the deliberate intent to be alternatives to regulations; this is almost always noticed by the other side, and tends to antagonize." This does not make sense out of context. Can someone who knows what's being said elaborate, or cut it out? Thanks Focomoso (talk) 09:23, 17 October 2009 (UTC)

WP:POINT guideline keeps instruction creep in place

Please help to overturn WP:POINT so instruction creep can be exposed. See Wikipedia_talk:Do_not_disrupt_Wikipedia_to_illustrate_a_point#This_guideline_keeps_instruction_creep_in_place 18.246.2.83 (talk) 08:18, 4 May 2010 (UTC)

"policies and guidelines should be as brief and simple as possible."

Is this a policy on policy and guideline editing? Koakhtzvigad (talk) 10:48, 13 February 2011 (UTC)

Its an "essay", not a policy or guideline, expressing good faith opinions based on experiences of the small group involved in editing it. PPdd (talk) 15:40, 26 February 2011 (UTC)

Creep in articles

This discussion regards these images and content. PPdd (talk) 16:00, 26 February 2011 (UTC)

I just reverted a bunch of edits that added a lot of content to this page. Although I thought there was some good material there, it seemed beyond the scope of this page, which is specifically about Wikipedia's policies and guidelines, not articles. Pages like this really need to focus on a single topic, so that when people refer to them their meaning is unambiguous. The material might be better in a user essay. (Incidentally, the Boiling frog story is probably not true [5].) Adrian J. Hunter^{(talk•contribs)} 15:43, 26 February 2011 (UTC)

(I didn't believe that a frog dropped in boiling water could jump out and live, either.)

From personal experience, the creep concept applied to many articles. It is identical to the concept as it pertains to guidelines and policies, and the same reasoning and examples apply. "Reverse creep" happened in many guidelines; when I went back to them I could not find any mention of applications of them that had been useful, as they had crept out, antd the entire focus of the guideline had changed by slow stepwise deletions.

The creep concept may even be more useful when applied to articles, than to guidelines and policies, since many more editors will see the problem when they are aware of it. PPdd (talk) 15:55, 26 February 2011 (UTC)

The other problem is that the term "instruction creep" originates from outside Wikipedia and applies specifically to instructions (and therefore, in Wikipedia, the policies and guidelines). I disagree that the process you're describing in articles is the same kind of thing. As I understand it, you're describing a mechanism of article degradation through a series of well-intentioned edits that are not individually problematic, but collectively cause WP:NPOV or WP:UNDUE problems. "Instruction creep" may also be due to a series of well-intentioned edits, but the problem is not with NPOV or UNDUE, but that instructional pages become so bloated that no-one reads them, and/or that the key points become lost in a sea of special cases. A similar mechanism, but a different problem. Have you considered creating your own essay, perhaps User:PPdd/Article creep? Adrian J. Hunter^{(talk•contribs)} 18:58, 26 February 2011 (UTC)

You are correct. Instruction creep and article creep both share creep, but have different applications. It's best to keep this article as simple and focused as possible. I will create another brief essay. PPdd (talk) 19:24, 26 February 2011 (UTC)

This essay is the opposite of accurate and sensible

Most of the time when the status quo zealots shout down any reform or proposal as "CREEP", it's not because that change would embody rule creep. The exact opposite is the case: Many changes are being opposed as "instruction creep" precisely when that change would streamline things and actually reduce the variety and arbitrariness of rules which some individual editors and groups of editors tend to build into a rule vacuum. So, I posit, almost anytime a proposed change is shouted down as "CREEP", that is actual rule creep. "per CREEP" has become the primary instrument of rule creep. Just stating the obvious since nobody else bothered to. --213.168.119.30 (talk) 14:04, 23 April 2012 (UTC)

This page does recognize that the status quo can itself be instruction creep. If you think this needs to be made more clear, go ahead and edit it. PSWG1920 (talk) 15:13, 29 August 2012 (UTC)

Changes

In regards to these changes:

"Bloat" doesn't seem necessary to include in the lead paragraph. PSWG1920 (talk) 17:48, 22 September 2012 (UTC)
"expand beyond brief and simple explanations" seems rather awkward. Imo it makes more sense with "what they are supposed to be". PSWG1920 (talk) 17:48, 22 September 2012 (UTC)
I understand the reason for splitting up what was the section "How Instruction Creep Develops", but both sections now seem to lack context. Previously, it was explained that policies function technically like articles but should be treated differently, but that point is now pretty much lost. PSWG1920 (talk) 17:48, 22 September 2012 (UTC)

You are right, "bloat" isn't necessary. That said, I think it is helpful in the introduction because the word is used often in edit summaries and discussions. But if you feel strongly that it should go somewhere else then don't let me stop you from moving it.
I'm not sure I follow your second point. "Expand beyond" is in both versions. "Brief and simple" is substituted for "straightforward." I'm not married to "brief and simple," so if you want to change it back to straightforward then be my guest. Finally, "what they are supposed to be" is eliminated. My thinking is that this phrase didn't add any real meaning to the sentence. Do you think it does?
I suppose we could add "Unlike content articles, ..." to the first sentence of Why instruction creep is discouraged. However, as I understand it, even content articles are not supposed to cover every minute aspect of the subjects with which they deal. So using that as the distinction might be inappropriate. Butwhatdoiknow (talk) 19:13, 22 September 2012 (UTC)

I moved "bloat" down into the body, replacing "lengthier and more complex".
I had thought that "what they are supposed to be" made it sound better. I guess there's no compelling reason for it, though.
I restored the previous "How instruction creep develops" section with a few changes. The overall context just seems better that way. PSWG1920 (talk) 16:33, 23 September 2012 (UTC)

Looks good. The one thing that bothers me is the section title. The content seems broader than "How instruction creep develops." Maybe something along the lines of "Why instruction creep is a problem"? Butwhatdoiknow (talk) 17:43, 23 September 2012 (UTC)

Maybe it could just be combined with the lead? PSWG1920 (talk) 18:23, 23 September 2012 (UTC)

Done. Butwhatdoiknow (talk) 12:18, 24 September 2012 (UTC)

I wonder whether the first part of this edit is an accurate definition of instruction creep (and, if it is, whether a separate essay saying that policies should reflect consensus is essay creep.) My understanding, drawn from m:Instruction creep, is that IE occurs when "instructions increase in size over time until they are unmanageable," even if each of the individual instructions reflects "true" community consensus. What do you think about reverting that part of the edit or, perhaps,replacing it with the phrase from m:Instruction creep? Butwhatdoiknow (talk) 12:18, 24 September 2012 (UTC)

To say that instruction creep occurs when instructions increase in size over time until they are unmanageable makes it easier to oppose any addition to policy as WP:CREEP. The point is that keeping policies simple makes them more transparent and thus more likely to reflect true community consensus, since something controversial would be noticed by enough users who would object to it. PSWG1920 (talk) 13:06, 24 September 2012 (UTC)

So much for my alternative "or, perhaps" suggestion. What about my primary proposal to return to "expand beyond brief and simple explanations of community norms"? Butwhatdoiknow (talk) 02:09, 25 September 2012 (UTC)

Sorry for the delay in responding. I was distracted, and also not sure what to think about this. I still find "expand beyond brief and simple explanations of community norms" awkward for some reason, but if you find the current wording too problematic, I will not object to changing it back. PSWG1920 (talk) 19:16, 28 September 2012 (UTC)

You are doing good work on reducing text-bloat on this essay. Keep it up! Butwhatdoiknow (talk) 22:56, 11 October 2012 (UTC)

I've shortened the lead. I thought unread and uninviting were pretty much the same point, so I combined them and tidied up from there. Perhaps the point about being unrepresentative could return to the lead, but it is covered in the body regardless. PSWG1920 (talk) 02:52, 15 October 2012 (UTC)

Well, I'll miss the structure. But brevity should probably be the primary goal with regard to this essay. Butwhatdoiknow (talk) 11:45, 15 October 2012 (UTC)

The problem was that two of those points were essentially the same. I'm not totally satisfied with the current lead, so feel free to try other things. PSWG1920 (talk) 19:10, 15 October 2012 (UTC)

RfC: Should WP:CREEP Be Promoted to a Policy or Guideline?

WP:NOT, an accepted policy, references WP:CREEP, which is an representation of WP:NOTLAW and (my favorite) WP:RAP. It's been debated for this essay to be promoted since March of last year, but no one has done anything, so I'm filing this RfC. ηoian ‡orever ηew ‡rontiers 06:03, 15 January 2010 (UTC)

Promote to procedural policy. This page describes a very good principle which should be followed in the development and maintenance of policy and guideline pages. PSWG1920 (talk) 21:03, 16 January 2010 (UTC)
Oppose as, well... WP:CREEP. It's just not needed, and it's perfectly usable as an essay. The reason essays are essays is because they document widely held viewpoints, regardless of any opposing views or reality within the Wikipedia community. Policies and guidelines should be much less opinion oriented, and shouldn't exist to try to impose rules (which this would attempt to do as a policy or guideline). It's a principle that most choose to espouse, just leave it that way.
— V = I * R (talk to Ohms law) 07:22, 20 January 2010 (UTC)
Comment This strikes me as meaningless and impossible to implement. what difference would it make if this were policy or an essay? are we going to start having official sanctions for people who try to make too many rules? It might make sense to make it a guideline (and I'd probably support that), but there isn't anything tangible enough here for policy. --Ludwigs2 07:59, 20 January 2010 (UTC)
Oppose - it's written in essay style, and the points made in "Avoiding instruction creep" can be summarised on existing policy pages, most obviously Wikipedia:Policies and guidelines. Basically, no benefit to it being a guideline, and it risks yet more overuse/abuse of reference to WP:CREEP, which already gets thrown around as a moralistic "I don't like it and I don't want to talk about it" response to proposals, as a substitute for reasoned discussion of pros and cons and possible alternative proposals etc. Rd232 ^talk 10:14, 20 January 2010 (UTC)
- See the section I recently added due to seeing such concerns in this page's talk archive. PSWG1920 (talk) 19:39, 20 January 2010 (UTC)
  Good addition.
  — V = I * R (talk to Ohms law) 05:24, 21 January 2010 (UTC)
Oppose per WP:CREEP. --Carnildo (talk) 00:16, 21 January 2010 (UTC)
Promote to guideline. Not directly actionable enough to be policy, but provides a very good and needed caution of what should not happen on policy and guideline pages, and giving it a bit more "bite" would be a good thing. Mildly ironic, yes, but the page is relatively short and seems to align with consensus. Even those opposing its promotion don't seem to be disagreeing with the page's substance. 93.167.245.178 (talk) 01:18, 29 January 2010 (UTC)
Oppose. There is a need for instructions and I have had editors citing this essay as a reason to not add what I considered to be suitable policies and guidelines. If it becomes a policy or guideline we may see good suggestions shot down with WP:CREEP. -- Alan Liefting (talk) - 09:00, 6 February 2010 (UTC)
- Again, see the recently added section Practical application. The purpose of this page is to prevent instructions which are not reflective of true community consensus. PSWG1920 (talk) 03:04, 7 February 2010 (UTC)
Oppose I have just come from "Wikipedia talk:Quotations#Proposal to promote to policy/guideline" after stating that promoting that essay would be instruction creep ditto. -- PBS (talk) 11:11, 14 March 2010 (UTC)
Oppose174.3.107.176 (talk) 15:35, 14 March 2010 (UTC)
- Just a pointer, if you want this promoted, define "instruction creep" better.174.3.107.176 (talk) 15:42, 14 March 2010 (UTC)
Promote Promote to procedural policy. This page describes essential principle which should be followed in the development and maintenance of policy and guideline pages. It does not only protect every rules but also qualifies them as evidence that they should gain support of significant users. It is important enough to be considered as a guideline even if the style of this document is like an essey.--P.Andretti (talk) 01:27, 6 June 2010 (UTC)
Oppose, per Rd232. -- Jrtayloriv (talk) 21:28, 26 August 2010 (UTC)
Nah. It's good advice sometimes, but it's used to justify inertia and that'd be made worse if it became policy. It's just something to bear in mind, not to etch in stone. Fences&Windows 22:15, 26 August 2010 (UTC)
Promote　It will keep wikipedia from bad constraint against the free policy. this check list is more important in some local project. On the other hand this rules doesn't make any adverse effects.--Miradorador (talk) 08:12, 6 June 2011 (UTC)
Comment Instruction creep (and instruction growth in general) is a bind, especially for new or newish contributors—including valuable topic experts who maybe don't feel a broader vocational interest in Wikipedia. It's a thorny issue that's likely to continue to grow in the absence of a concerted move to prune the plants. However, I cannot see how straightforward promotion of WP:CREEP to policy status would be effective, at least in the absence of a clear-cut definition of what constitutes "creep", accompanied by greater practical advice on how to tackle it and avoid inadvertently propagating it... Otherwise, it might just join the other creepers. I think alternative interventions need to be considered. For example: by weaving the rationale of WP:CREEP into policy and guidelines; by introducing stronger measures to keep local guidelines in line with general guidelines unless there's a compelling reason to fork (as sometimes does happen); by introducing smart forms of housekeeping; etc. A pair of secateurs, —MistyMorn (talk) 12:23, 26 February 2012 (UTC)
Comment. I guess the most essential points of this page are already policy. PSWG1920 (talk) 22:42, 27 October 2012 (UTC)
Comment. The current page is not a guideline, it is an observation that, "Guidance that is too wordy and tries to cover all the bases and every conceivable outlying case tends to become counterproductive." Since this doesn't provide guidance it would seem strange if it was considered a guideline. Hyacinth (talk) 07:02, 16 March 2020 (UTC)

Nutshell

In regards to this revert, WP:MTAU is about articles. WP:CREEP is about understandability as well as succinctness. The current nutshell is not bad, but it is a bit long. PSWG1920 (talk) 21:06, 5 October 2014 (UTC)

Nah, I don't think you understood the essay very well. The replacement you proposed is not a summary of this essay. It refers to other, related ideas, but not this essay. The essay doesn't say to dumb things down. It doesn't say to make guidance necessarily more succinct. It doesn't say to make guidance more broadly intelligble. These are other goals, part of them also laudable, but not the essence of this essay. --Francis Schonken (talk) 21:27, 5 October 2014 (UTC)

I understand this essay. It doesn't say instructions should always be succinct per se, but it does say they should be understandable. The current nutshell is OK, but it sounds a bit awkward. Maybe it could start with "To avoid overcomplexity,". PSWG1920 (talk) 01:47, 6 October 2014 (UTC)

Avoiding overcomplexity is more a corrolary, than the first reason why. Don't think that would be an improvement for the nutshell. --Francis Schonken (talk) 06:15, 6 October 2014 (UTC)

Well, let me give an example: WP:COP#Ordering names in a category is "not succinct" and really, unless one expects a general audience to be both categorization geeks, and accustomed to collation habits encompassing all languages, regions and eras, "overly complex" (for a general audience). Yet, I see no tension with WP:CREEP, because that piece of guidance is "in line with community consensus", addressing a real issue, and explaining the techniques to address it as understandable as possible for those trying to remedy the problems associated with it. There would be a tension with "Wikipedia policies and guidelines should remain succinct enough to be understood by a general audience" as well as with "To avoid overcomplexity,..." — which would be misleading nutshells. In other words, the guidance I referred to is long and complex, but not hopelessly so (as the current wording of the nutshell has it), because of its wide-reaching practical value. --Francis Schonken (talk) 09:25, 6 October 2014 (UTC)

Giving a contrasting example: in this discussion I opposed a minor rewording of a guideline (basically no more than giving another set of examples), for a WP:CREEP reason: "I don't want to legislate something that is not a current issue" [6] — Note that the change I opposed proposed more clarity in the guidance, so neither complexity issues nor understandibility issues were served by opposing the change, only the proposal involved addressing "possible", but not actual problems, so WP:CREEP per the current nutshell, not, however, by the rewordings proposed for that nutshell. --Francis Schonken (talk) 10:28, 6 October 2014 (UTC)

In sum, in my view, Wikipedia:Avoid instruction creep is more about the application of Wikipedia:If it ain't broke, don't fix it in the context of Wikipedia guidance, than about the application of Wikipedia:Make technical articles understandable outside main namespace, and I oppose rewordings of the essay or its nutshell that would give another impression. --Francis Schonken (talk) 10:40, 6 October 2014 (UTC)

OK, I see what you're saying. Maybe the nutshell could say something about sticking to the important points? PSWG1920 (talk) 03:06, 7 October 2014 (UTC)

The essay might also say something about editor discretion (but in a wider sense than what is in the Wikipedia:Editorial discretion essay), as the alternative to instruction creep. Don't know whether that would go in the nutshell though. --Francis Schonken (talk) 05:57, 7 October 2014 (UTC)

I just changed the nutshell to "Wikipedia policies and guidelines should not be more complex than is necessary to serve their purpose." It could be even shorter: "Wikipedia policies and guidelines should not be more complex than necessary." But I'm not sure if that would really convey the point. PSWG1920 (talk) 05:34, 9 October 2014 (UTC)

Neither does. There's also no goal as such to make the nutshell "shorter". --Francis Schonken (talk) 05:37, 9 October 2014 (UTC)

How about "Wikipedia policies and guidelines should stick to the important points, rather than addressing every possible problem." PSWG1920 (talk) 18:56, 9 October 2014 (UTC)

"Important" is such a vague concept that it gives less clarity than using length and complexity as corrolaries. "should not address every possible problem" as central and first message in the nutshell works better for me. --Francis Schonken (talk) 19:41, 9 October 2014 (UTC)

Just picking up what I ran into: here's something that might serve as a base for an improved nutshell: "guidelines (...) that are too wordy and try to cover all the bases and every conceivable outlying case are counterproductive." [7] --Francis Schonken (talk) 08:41, 14 October 2014 (UTC) How about this:

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.

? --Francis Schonken (talk) 08:57, 14 October 2014 (UTC)

Maybe "Wikipedia's written rules should not aim to cover every outlying case." PSWG1920 (talk) 05:19, 17 October 2014 (UTC)

"counterproductive" is a good summary of the why for me. --Francis Schonken (talk) 05:35, 17 October 2014 (UTC)

What NOT to do

@Hyacinth: if you want to find a new consensus for the nutshell: do it here before changing it. --Francis Schonken (talk) 05:59, 16 March 2020 (UTC)

@Francis Schonken: What's your objection, or do I have your support? If you don't want me to talk to you on your talk page don't talk to me in edit summaries (instead talk about the page and your objections to the change, not about me). If you want to tell me what to do you should be pleased that I want to ask for your assistance and opinions. Hyacinth (talk) 06:13, 16 March 2020 (UTC)

Re. "... do I have your support?" – No, I think the 2014 wording of the nutshell needs no emendation. --Francis Schonken (talk) 06:20, 16 March 2020 (UTC)

@Francis Schonken: Why can't the nutshell usefully tell users what to do instead of telling them vaguely what not to do? Hyacinth (talk) 06:23, 16 March 2020 (UTC)

Why would that be a useful change? seems like WP:CREEP to me. --Francis Schonken (talk) 06:26, 16 March 2020 (UTC)

Being unread by the majority of people is the universal fate of all written material. Talking about it as if this is specific to Wikipedia is both misleading and reading that a rule that says that rules won't be read doesn't give the reader anything useful such as information or advice on how to write better policies or reduce the number of policies. That is WP:CREEP. Hyacinth (talk) 06:32, 16 March 2020 (UTC)

Similarly, telling a user what not to do serves little purpose. WP:Don't pick your nose wouldn't be a useful policy or guideline because it tells editors what not to do, but does not indicate at all what they should do. This undermines the credibility of WP:CREEP when it is invoked to argue that something should be done a certain way. To strengthen this policy Wikipedia needs positive advice, not just negative advice. Hyacinth (talk) 06:41, 16 March 2020 (UTC)

Other editors appear to frequently misinterpret my intentions. To be clear I am not trying to destroy this policy. I am trying to strengthen the policy by dealing with its contradictory arguments and having it provide positive advice instead of purely negative advice. If I wanted to write a bunch of policies I would be doing that instead of looking at this page. Hyacinth (talk) 06:47, 16 March 2020 (UTC)

The current nutshell is an observation, not advice, yet the page is categorized in "Wikipedia competence essays" and "Wikipedia essays about style" despite it not providing information that increases competence or informs style. Hyacinth (talk) 06:56, 16 March 2020 (UTC)

"Succinct"?

Challenged to formulate positively what Wikipedia guidance should look like (rather than only what it shouldn't look like), in the context of the WP:CREEP guidance, I suppose the major positive quality of all Wikipedia guidance we'd be looking for here is succinctness, and that the WP:CREEP guidance is where that should be described. To my surprise, the current WP:CREEP page doesn't contain that word, not even once, so I'd support to use it for describing, in this guidance page, what we'd expect positively of guidance in general. --Francis Schonken (talk) 07:42, 16 March 2020 (UTC)

Redundant: Bases and cases

The phrasing, "cover all the bases and every conceivable outlying case," is redundant. It should read, "every conceivable outlying case," and omit "cover all the bases" since that is metaphor which means the same thing. Hyacinth (talk) 07:00, 16 March 2020 (UTC)

Contradictions

@Butwhatdoiknow: WP:CREEP currently appears to use two contradictory arguments.

Pragmatic: that policy should be succinct so as to be effective as possible.
Pessimistic/nihilistic: that policy is completely useless irregardless of brevity or excess.
- Aesthetic: that some people find any and all policy objectionable without specific causes for disliking specific policies.

I would suggest that these arguments be articulated at different pages, one of which is pragmatic and one of which is not (perhaps WP:CREEP and WP:As a rule, rules make me mad or WP:As a rule, the only good rule is a rule against all rules). Hyacinth (talk) 04:51, 16 March 2020 (UTC)

I'm not sure that I agree, but I am sure that I'm not the arbiter. I have reverted your "including this page" edits because I find them to be self-evident and unnecessary (which makes them in violation of both "arguments"). I fail to see the connection between my reversions and what you now raise as inconsistencies within the essay. Butwhatdoiknow (talk) 06:01, 16 March 2020 (UTC)

Afaics "policy is completely useless irregardless of brevity or excess" is nowhere implied on this page. so I don't understand the proposal/suggestion above. Hence my question: Hyacinth, what is your objective here? I don't see what you're trying to accomplish? --Francis Schonken (talk) 06:04, 16 March 2020 (UTC)

A policy that is never read by any editors can't be useful no matter how well written or brief. The rate at which editors read policies in general has nothing to do with specific policies being created, deleted, well written or poorly written, good or bad, and useful or useless. Hyacinth (talk) 06:11, 16 March 2020 (UTC)

Afaik the WP:CREEP explanatory supplement is well read, and applied where appropriate. So, from that perspective there's no reason to change it. Where did you experience a problem with applying this guidance? If there would be no such practical problem occurring in practice, there should be no attempts to fix what isn't broken. So, unless you can point to a real example of something that went wrong when applying, or trying to apply, this guidance, I suppose this discussion thread can be closed. --Francis Schonken (talk) 06:18, 16 March 2020 (UTC)

Added {{Annual readership}} above, to see whether or not the page is "well read" – afaics it is. --Francis Schonken (talk) 08:01, 16 March 2020 (UTC)

@Butwhatdoiknow: Do you agree that this discussion should be closed? Hyacinth (talk) 06:36, 16 March 2020 (UTC)

So, you're admitting there was no real problem with the guidance before you started messing with it? --Francis Schonken (talk) 06:43, 16 March 2020 (UTC)

We're both getting our discussion of two separate issues mixed up. Hyacinth (talk) 06:49, 16 March 2020 (UTC)

Why is it a priority for you that what seems like a criticism of this policy (but is actually an apparently poorly made suggestion for improvement) be closed and archived? I think that WP:CREEP is strong enough to tolerate criticism and that my comments on the talk page, which you asked for, pose no threat to WP:CREEP. Hyacinth (talk) 06:52, 16 March 2020 (UTC)

The "two contradictory arguments" discussion? At this point I have no opinion regarding that. The opinion I do have is that your continuing to edit the essay itself after being continuously reverted is disruptive and should stop. Butwhatdoiknow (talk) 15:36, 16 March 2020 (UTC)

New edit notice to help fight CREEP

I've just created Template:Simple help page, an editnotice for simple pages targeted at beginners (e.g. WP:Plain and simple conflict of interest guide). Please help spread it by adding it to appropriate pages! {{u|Sdkb}} ^talk 04:35, 6 June 2020 (UTC)

Throwing the baby out with the bathwater?

@Francis Schonken: Over the past month and a half I (and, briefly, one other editor) have made small, incremental changes to WP:Avoid instruction creep. Today, you reverted each and every one of those changes. Did you find nothing worth keeping in all the edits made in the past month and a half? Butwhatdoiknow (talk) 20:13, 16 November 2020 (UTC)

Please explain first *why*? Seems you were trying to address a non-existing issue... incrementally. Besides, the other editor's edits were rather disruptive, except for (correctly) changing "polices" to "policies" – while the other instance of incorrect spelling of that word appears to have (also) been introduced by you. --Francis Schonken (talk) 20:53, 16 November 2020 (UTC)

October 4 edit

Okay, let's start with my first edit. The answer to your question as to that edit is that I believe the removed text is, as I said in the edit summary, "obvious to the newest of newbies" (or, put another way, the text doesn't solve a real problem). Butwhatdoiknow (talk) 22:23, 16 November 2020 (UTC)

Disagree. Removing it didn't address any real problem (it made the page worse for newbies). No consensus on this change, currently. --Francis Schonken (talk) 06:17, 17 November 2020 (UTC) Amended per suggestion at #Discussion regarding discussion below. Francis Schonken (talk) 16:20, 22 November 2020 (UTC)

Discussion reaching consensus regarding "no consensus" concern

Let's start with the "lack of consensus" rationale. More than 150 editors have this page on their watchlists. None of those editors reverted this change for a month and a half. Will you agree with me that, in this case, "lack of consensus" means little more than that you disagree for the other reasons you have given?* (If so, we can move on and talk about those other reasons.) Butwhatdoiknow (talk) 16:20, 17 November 2020 (UTC)

* "Editors who revert a change proposed by an edit should generally avoid terse explanations (such as "against consensus") which provide little guidance to the proposing editor ..." Wikipedia:Consensus#No_consensus Butwhatdoiknow (talk) 16:20, 17 November 2020 (UTC)

@Francis Schonken:, please continue this discussion. (Feel free to delete this post when you do.) Butwhatdoiknow (talk) 15:58, 21 November 2020 (UTC)

Was still waiting for a reply to "Please explain first *why*?" --Francis Schonken (talk) 16:00, 21 November 2020 (UTC)

You reversed a month and half of edits. There is not a single "why." Instead, there are separate whys for each edit. Hence, I responded to your "Please explain first *why*?" post with "Okay, let's start with my first edit. The answer to your question as to that edit is ..." In short, my November 17 post was a continuation of our first *why* discussion. I look forward to your substantive response. Butwhatdoiknow (talk) 18:11, 21 November 2020 (UTC)

If you want to discuss one by one that's OK for me. I replied to that one. But the rationale for a single edit doesn't answer my over-all "why" question – or does the same rationale apply to your other edits too? In which case the "why" clarification is answered too: let's not make this page less friendly for newbies. I just thought there was more than that, excuse me if that is not the case. --Francis Schonken (talk) 18:25, 21 November 2020 (UTC)

Why did I make all of those edits over a month and a half period? Because I thought they improved the article. You disagree. I don't see how we can resolve our differences if we don't look at whether each edit did or did not improve the article.

With that in mind, I saw your November 17 response (above) to the first edit as raising three concerns: (1) didn't address any real problem, (2) made the page worse for newbies, and (3) no consensus for the change. My November 17 reply (above) was intended to further discuss concern no. 3. To get back on track I request that you reply above to my November 17 post. Butwhatdoiknow (talk) 20:50, 21 November 2020 (UTC)

Re. "... our differences ..." – I thought it was forbidden to imply that our opinions currently don't align? --Francis Schonken (talk) 05:07, 22 November 2020 (UTC)

Sorry, I don't understand. If you meant this as humor, please explain the joke. If you meant this seriously, please elaborate (who or what forbids us from having differing opinions?). Butwhatdoiknow (talk) 05:31, 22 November 2020 (UTC)

"... differences ..." implies lack of consensus. Apparently you're allowed to express that, and I'm not. --Francis Schonken (talk) 06:25, 22 November 2020 (UTC)

Ah, I see what you are saying. Yes, disagreement may, indeed, indicate a current lack of consensus. But that does not foreclose a future consensus. "When agreement cannot be reached through editing alone, the consensus-forming process becomes more explicit: editors open a section on the associated talk page and try to work out the dispute through discussion." Read more here: Wikipedia:Consensus#Through_discussion.

That is one of the reasons I suggested on November 17 (above) that saying "'lack of consensus' means little more than that you disagree." Unlike the other two reasons you give ((1) didn't address any real problem, (2) made the page worse for newbies) it doesn't raise an issue for discussion. And this is particularly so when, as in this case, you reverted a month and a half old edit on a page with more than 150 watchers - none of whom reverted the edit when it was made. So, again, I ask for your agreement that we put your third reason ((3) no consensus for the change) aside and concentrate our discussion on your first two reasons for reverting my October 3 edit. Butwhatdoiknow (talk) 16:05, 22 November 2020 (UTC)

Amended my 06:17, 17 November 2020 (UTC) comment above accordingly, hope the wording is sufficiently clear now. I suggest we close the off-topic side-discussion forthwith: appears my reply to the issue has been sufficiently exhaustive. --Francis Schonken (talk) 16:20, 22 November 2020 (UTC)

Made page worse for newbies

Francis (may I call you "Francis"?), I'll agree that the information in the text I removed ("Like articles, most policy and guideline pages can be edited by any user.") would benefit the small subset of editors who don't have that information already by the time they read WP:CREEP. But let's think about this. How would an editor end up on the WP:CREEP page? Most likely by clicking a link to it in the edit history or on the talk page of a WP-space page. Will you agree with me that, by the time a non-oblivious editor has gotten that deep into WP-space the editor would already know that any user can edit WP-space pages (including policies and guidelines)? Butwhatdoiknow (talk) 18:11, 22 November 2020 (UTC)

I have no problem whatsoever to be called by my own name, if that is what you mean. I'd like not to see this as a dialogue between two persons, however, as that might be perceived as less inviting for other editors to join in. Thus, I'd mostly formulate my replies and suggestions on this talk page rather as general, than as personalised. That is my choice, hoping more editors will join in.

A general point: there might have been a general plan to bring this explanatory supplement more in line with its own recommendations, that is, e.g., weed out verbosity and excessive detail. There hardly seems to be any need for that: as is, the page is one of the shorter guidance pages. A counterpart of verbosity and excessive detail is, e.g., terseness. Guidance that is too terse also doesn't get read, and its implications are often even less understood – whether Wikipedia already has a guidance page about that aspect or not. As is, I suppose I think that the current page strikes a good balance, somewhere in the middle between verbosity and terseness. That doesn't mean improvements wouldn't be possible, but an eye has to be kept on the verbosity/terseness balance. I also think that mostly it wouldn't be a good idea that editors who are insensitive to the verbosity vs. terseness aspect rewrite the guidance. Case in point: if "No consensus on this change" is already experienced as too terse, then why introduce similar terseness in the WP:CREEP guidance?

As to the aspect of making newbies feel welcome: I already replied to that. Sorry if my reply was too terse. I can still write at least half a page about that, which then might be tending towards verbosity. --Francis Schonken (talk) 07:46, 23 November 2020 (UTC)

With regard to your general point, I agree that in a close call it is best to err on the side of too much information. Will you agree that information should be excluded when the call is not close? Butwhatdoiknow (talk) 16:24, 23 November 2020 (UTC)

Depends on who is calling the shots on what is a close call and what isn't. If that isn't clear, it should come to the talk page, like in the kind of discussion we're having now. --Francis Schonken (talk) 08:39, 24 November 2020 (UTC)

Your clarification is well taken. Editors can and will disagree regarding whether an in-or-out determination is a close call. With that in mind, can we agree that information that addresses a real problem should be in a policy or guideline and information that doesn't should not, with close calls going to inclusion? (With the further clarification that editors can and will disagree regarding whether any particular information addresses a real problem or not.) Butwhatdoiknow (talk) 15:17, 24 November 2020 (UTC)

@Francis Schonken:, please continue this discussion. Butwhatdoiknow (talk) 22:10, 29 November 2020 (UTC)

@Francis Schonken: Okay, that's your second reversion. Which would be fine if you were working with me toward a consensus. But you're not. Again, I request that you continue this discussion by replying to my November 24 post. Butwhatdoiknow (talk) 22:31, 3 December 2020 (UTC)

@Butwhatdoiknow: This is a joke, right? You want to expand what it says on our instructions regarding instruction creep? None of your edits are useful, you've failed to explain here what value-add your text provides, and you have not developed consensus for changes. Further, you've now provided evidence for a WP:IDHT mentality. Please stop your editing here. Chris Troutman (talk) 17:39, 17 December 2020 (UTC)

@Chris troutman: Actually, my edits narrowed the instructions regarding instruction creep. Case in point, my October 4 edit that the other editor restored as part of the mass revert. Butwhatdoiknow (talk) 22:34, 17 December 2020 (UTC)

That edit wasn't useful. The first sentence sets up the concept that the needless editing of articles is paralleled by the needless editing of policies and essays, like what you're trying to do. Please stop. Chris Troutman (talk) 01:15, 18 December 2020 (UTC)

Your first issue with my edits was that they added instructions. I think it is safe to say we now agree that at least one of them didn't. Butwhatdoiknow (talk) 02:34, 18 December 2020 (UTC)

@Chris troutman: You also criticize a failure on my part to explain the benefit of my edits. I was in the process of defending my first edit (the October 4 edit) on talk when the reverting editor ghosted me. At that time no one else was objecting to any of my edits. So there was no one left to explain anything to. How do you recommend I explain my edits in such a situation? Butwhatdoiknow (talk) 02:34, 18 December 2020 (UTC)

If there's no value in your edits and they're reverted, per WP:BRD it's time to discuss. I acknowledge that you don't think you were given the discussion you deserve. Francis Schonken has since explained that your edits are not value-add. You could have asked for a third opinion. Don't think that Wikipedia has to provide you vociferous, immediate response to your edits. I consider the issue done, as you don't have consensus for these changes. Chris Troutman (talk) 19:58, 18 December 2020 (UTC)

Thanks, I'll try WP:3PO next time. (Whether or not Francis Schonken "owed" me a response, it would have been nice if, instead of ghosting, he'd extended me the simple courtesy of telling me he would no longer discuss the issues raised by his mass revert.) Butwhatdoiknow (talk) 21:14, 18 December 2020 (UTC)

Explanation of December 16 revert

Prior Edits and Discussion

On November 16 another editor did a single edit reverting 19 changes I had made to this article over a period of a month and a half. The reverting edit summary referred only to the 19th change. The other editor and I began a discussion on the talk page.
On November 17 the other editor dropped out of the talk page conversation. The editor resumed the conversation only after a November 21 prompt.
On November 24 the other editor once again dropped out of the conversation. The editor did not resume the conversation after a November 29 prompt.
On December 3 I reached out to the other editor and was rebuffed. Later that day I undid the other editor's November 16 mass revert edit, citing that editor's failure to cooperate in a discussion to reach consensus.

The Edit I Am Reverting

Still later on December 3 the other editor again reverted. The editor did not return to the talk page. However, in the edit summary the editor gave two reasons:

(a) "none of this has consensus" and

(b) "no rationale could even be given on talk."

Any Lack Of Consensus Is The Result Of Other Editor Failing To Discuss

This page has more than 100 watchers. The fact that, for example, no editor reverted my October 4 edit between that date and the other editor's November 16 mass reversion indicates that the October 4 edit had consensus. See WP:Consensus#Through_editing: "Any edit that is not disputed or reverted by another editor can be assumed to have consensus."
Regardless, as the other editor agreed, consensus can change. (Hence, quoting WP:CCC: "Editors who revert a change proposed by an edit should generally avoid terse explanations (such as 'against consensus') which provide little guidance ...")
Editors cannot prevent consensus from changing by refusing to discuss. See WP:Consensus#In_talk_pages: "Editors who ignore talk page discussions yet continue to edit in or revert disputed material, or who stonewall discussions, may be guilty of disruptive editing and incur sanctions."
As set forth above, the other editor has abandoned the talk page discussion. That editor's continued use of the "no consensus" rationale rings hollow.

I Have Given Rationales On Talk

As the old saying goes, folks are entitled to their own opinions but not to their own facts.
The other editor is entitled to the opinion that my rationales are unpersuasive.
But that editor is not entitled to deny the fact that I gave substantive rationales in the summaries of my original edits and in our talk page discussion,

Conclusion

I am undoing the other editor's most recent reversion because, as explained above, (a) the other editor has ceased communicating on talk and (b) neither rationale the other editor gave for the most recent reversion supports a revert.
I welcome the other editor back to the talk page to resume the discussion of our differences by replying to my November 24 post. And, if that editor accepts that invitation, I have no objection to that editor once again reverting pending the outcome of those discussions. Butwhatdoiknow (talk) 18:34, 16 December 2020 (UTC)
Sorry but WP:TLDR applies. The page in question is one rung above an essay and it does not warrant indignation or homely thoughts about other editors. By the way, in a quick look of the diff, I wondered if you inserted a space in a shortcut links, for example "WP: TLDR". That would be a very unusual style. Johnuniq (talk) 02:21, 17 December 2020 (UTC)
@Johnuniq: Would you please help me understand what text in my post gave the impression of indignant or homely thoughts? (Regarding the last sentence of your post, I did not intentionally insert a space in any shortcut links.) Butwhatdoiknow (talk) 03:51, 17 December 2020 (UTC)

Johnunig has, elsewhere, declined to further explain how my post expressed "indignation or homely thoughts about other editors." Butwhatdoiknow (talk) 16:16, 7 January 2021 (UTC)

For the record: the other editor's behavior toward me and a number of other editors has now resulted in a consensus to impose a community ban on the other editor. This does not change the fact that I expressed my frustration with the other editor ineptly and I hope to learn from this experience and be a better Wikipedia editor in the future. Butwhatdoiknow (talk) 21:54, 16 May 2021 (UTC)

Changes since August 4

Sorry to be blunt but the changes since 4 August 2021 include broken English. For example, in the nutshell, "When editing guidance" is not right. I can see that some of the adjustments move in the right direction, for example, the semanticscholar.org reference that was removed is junk. Are you sure all this turmoil is worthwhile? Johnuniq (talk) 05:12, 22 August 2021 (UTC)

No worries with regard to good faith bluntness. (Or, as I might put it: "With regard to good faith bluntness, no worries.")

To the extent you object to my grammar then I welcome any fix you care to make. To the extent you have any concern about the substance of the edit you gave as an example, please see my edit summary explaining the reason for that change.

I'm not sure what you mean by "worthwhile." Obviously, the project is one to which I have decided to devote effort, so I must think it's worth my time. I'm also not sure what you mean by turmoil. There was turmoil in the past caused by an editor who did not understand the Wikipedia consensus process. But, with the exception of your post questioning my grammar, no one has questioned the recent changes I have made. - Butwhatdoiknow (talk) 16:58, 22 August 2021 (UTC)