Wikipedia:Practical process

"You know how Wikipedia was having a funds drive recently? They should open a shop selling spools of Wikipedia branded red tape" — Dan Lane

Process is important to writing the encyclopedia or we'd all kill each other. Following process really will avoid confusion. But that doesn't mean more process is therefore better. Most people don't read and remember all of the millions of words of Wikipedia process. If our process does not follow obviously and elegantly from Wikipedia's few fundamental policies, editors will not remember it or understand it.

Process bloat is an ever-present danger. Process is added on the spot as needed; it must be pruned and sanity-checked regularly.

Process is only a means to the ends that policy spells out. Core policy is solid, but process must stay fluid.

The function of process

Further information: Wikipedia:Process is important

We're here to write an encyclopedia. Process is the temporary scaffolding we put up to help us write an encyclopedia.

Having no process or not working to established process leads to chaos. We use process:

1. To give some consistency in similar situations. This helps process feel fair, even though precedent is not binding on Wikipedia.
2. To reduce the redundant effort of making each and every decision from first principles.
3. To encourage institutional learning and lead to a higher overall quality of decision making.

Following process reduces confusion — editors don't feel the ground shifting under their feet.

The core content policies of the English Wikipedia are neutral point of view (NPOV), verifiability and no original research. Our equally important community policies are assume good faith (AGF) and no personal attacks (NPA). You may want to think of don't bite the newbies (BITE) as part of the "core" list, since newcomers seem to write most of the actual content.

How process is created

We have lots of processes, small and large, on Wikipedia. We have portals for topic-based editors, templates for organization types, different deletion pages for different styles of inclusion/deletion sorts, different admin pages for different admin styles, guidelines, policy pages, etc. These are ultimately all skins and mechanisms for poking at a Wikipedia that is by now far too big and distributed to actually control.

Almost all our processes are quick hacks to achieve a temporary result. They are created, they work and the result is accepted in day-to-day practice. But they should be regarded as largely the bodgy hacks they are, to be thrown away when they are more trouble than they are worth, or when a different, better approach is realized.

The danger of process cruft

Kudzu was invented to supply similes for process.

Process is created ad-hoc as needed, but is rarely examined and removed. This can result in a confusing mass of process that appears incoherent ... because it is. An excess of process leads to bureaucracy and confusion and people claiming all process is bad because much of it demonstrably is.

The process to enact the fundamental policy must stay completely malleable. This is why Ignore all rules is policy.

The parable of process

A well-intentioned newcomer, Kid Dubose, arrives at Wikipedia and loves it, and starts writing and editing stuff. He looks around to find our rules, so that he can do things the way we do things here, however that is. Many of the rules he finds are, unbeknownst to him, temporary hacks with more hacks on top. But Kid's a responsible, law-abiding sort, so he sets about to follow these rules and processes carefully as he begins his career as a Wikipedian. He's smart and has a head for detail, so he does okay.

As he interacts more with other editors, however, he discovers that the de facto realities of the community don't seem to match the de jure rules he's trying to follow. There seem to be a lot of complex cases which the rules don't cover, there seem to be a lot of other editors who are pretty cavalier about the rules or are simply making things up as they go along, and there's an awful lot of vigorous handwaving and shouting about all of this.

Kid tries valiantly to stick to the rules. Actually, he does a good enough job that he seeks and is granted adminship. But then his miseries really begin. As an admin, he feels that enforcing rules and procedures is not merely a good idea, it's a mandate of the position. But he finds himself in more and more heated arguments with more and more clueless editors who keep overlooking or misunderstanding some policy or another. Worse still, Kid finds himself locking horns with other admins, who have different interpretations of the rules and are trying to apply them differently than Kid is.

Eventually, Kid becomes depressed and disillusioned about the frustrations of his position, the intransigence of his fellow admins, and the wanton stupidity (as he sees it) of the madding crowd of editors. He hangs up his admin bit and bids Wikipedia an angry goodbye.

* * *

People see processes that are quick hacks built out of gaffer tape and string (especially the fragile politicised compromises hammered out over much argument), but assume they are all polished stainless steel devices of immaculate and well thought-out design that mesh together seamlessly. There is an unfortunate tendency to treat processes as received wisdom. Some editors will even engage in a revert war to keep someone else from changing process, behaving as though anyone trying to fix a broken hack is introducing a loophole to subtly trash the encyclopedia.

Process exists to help clueful editors of good will work more efficiently, not to beat other editors over the head with, or to lay the ground for internecine civil wars. When there's a discrepancy between a formal process versus an obvious right thing to do in a special situation, then, if the obvious thing doesn't violate NPOV, NOR or V, it may be preferable to bend, ignore or create an exception to the rules, rather than standing on ceremony and stoking a messy fight. Judge on results. An exception does not necessarily destroy a process, and can be quietly ignored later. Fights are always destructive, and difficult to ignore.

Complex process excludes people

All of our success has come from staying as open as we possibly can. If it's not easy to edit, it's not a wiki. Excess process wears editors down and leads to volunteers disengaging and going home, which is directly damaging to the project.

In the worst case, the rules exact their cost — stifling initiative and creativity, taking on a life of their own requiring significant resources to maintain, parasitizing the rest of the enterprise — and deliver none of their benefits. You then also bear the costs of no rules: fallible human judgement and the anarchy of people doing what they want and fighting over whether they're allowed to.

The more rules, the less article writing. Process that hampers the addition of content must have severe justification. Don't bite the newbies. Wikipedia always needs new editors — new and occasional editors, not the regulars, in fact write most of the content. New editors must not feel like they've fallen down the rabbit hole or into a stultifying maze of bureaucracy. They need to be given a bit of leeway, or they will not feel free to actually add content. They must be able to write with only the most basic rules.

Overworked regulars form inadvertent committees

In some areas, processes are set up such that an ad-hoc group of Wikipedians will vote or discuss the matter. As the process page gains regulars, these can form into virtual committees. Any regular voting situation is susceptible to this.

Committees often fail to scale with editors and articles. The overworked regulars then tweak process to make the process page easier for themselves – formalised systems, local jargon and so forth. This unintentionally excludes outsiders from the pages. Many express open suspicion of outsiders, who are perceived as not knowing how the process works. Regulars lose sight of the big picture and begin to conflate the process with the project and will defend the process at the expense of damage to the project. (e.g. on Articles for deletion, regulars bitterly resisted and reverted all attempts to break the page up from one long 2-megabyte lump of HTML into individual day pages until the developers made it clear that that one page alone was causing notable server problems.)

How to write a process for mere humans

When something bad happens, people tend to add a new rule to stop it from happening again. But special cases make bad law. Bits bolted on the side as they occur to you are unlikely to be robust.

If you want people to understand, let alone follow, your process, you need to keep it simple. Less is more. Assume your process will be carried out by enthusiastic but imperfect humans, who will get the idea but not memorise the details. A robust process has to follow clearly from the fundamental policies or people forget it.

Exercise: try writing a one or two-sentence nutshell (with no comma clauses) that the whole process follows from. Make sure the nutshell follows as directly as possible from the core policies.

(Most of the text below is things not to do, because not adding process fast enough is not yet as much as a problem. Please add examples of such to the talk page.)

Humans are not robots

Human judgement is flawed, imperfect and subject to bias and abuse. So some people assume the goal is to write reliable procedures for all actions and eliminate grey areas, in the interests of fairness and efficiency.

But there's no mechanical procedure for good sense, the process structure is not complete, coherent or consistent, and precedent isn't binding in any case.

The more rules, the harder it is for people to follow them. So they won't.

That Wikipedia is inconsistent, and permits things it does not condone, is a feature. Take care not to try to turn Wikipedia into something which, if it was, would never have become interesting enough for you to have heard about it in the first place. See The Goose That Laid the Golden Eggs.

You can't legislate against misunderstanding or malice

"... it's hard work for people to think."

Process is to help editors of understanding and good faith. It can't really stop uncomprehending or malicious ones — adding a new rule won't change their behaviour a dot, and will hamper the good editors. Simpler and clearer rules are easier to follow and more likely to be remembered.

Take care not to write something susceptible to idiocy or abuse — but if you have to dangle subclauses and exceptions off your rule to avoid obvious abusability, work more on what you're saying. Special cases make for a lumpy and hard-to-follow page.

No rules can ensure quality, no rules can ensure neutrality, no rules can prevent cluelessness and no rules can prevent malice. "But I followed process!" is missing the point of having process.

Give judgment its due

Just because something doesn't work perfectly doesn't mean a new process is needed to "fix" it. Consider doing nothing or reducing a related process. Requiring human discretion is expressly [1] part of the Wikipedia system — can it take care of the special case?

Sometimes an issue may be decided with a somewhat arbitrary choice because any choice is better than none. But nailing everything down for the sake of a decision being made seems to create arguments rather than efficiency. (e.g. notability guidelines that pick a number or are susceptible to cultural bias.) If an area is obviously subjective, any arbitrary decision must be such as not to give much room for legitimate disagreement.

Some people write things as hard rules because it is important for others to follow them. Editorial guidelines get phrased as didactic policy. This results in phenomena such as Wikipedia:Reliable sources (a guideline) being taken as robotic instructions, regardless of damage to the articles (gutting them of content) or damage to public relations (people kept from clearing up press errors in the articles about them), or used as a bludgeon by POV warriors.

Phrase as guidelines wherever possible. If you assume your reader has judgement, you can save a lot of work and extra text. (e.g. the rewrite of Wikipedia:Blocking policy could have included a discourse on the pros and cons of "cool-down" blocks, but instead just said "Consider whether a 1-hour block will result in 2 months' drama.")

Give good sense room to breathe. Everything that can be a guideline should be, because clueless editors won't understand it and bad faith editors won't care.

Process that's hardened into policy

It is common to speak of very important and widely-agreed process as "policy" (e.g. Blocking policy, Three-revert rule). This is for things that are very important to nail down, and that are sufficiently lacking in grey areas that they can be codified and phrased as imperatives without becoming a playground for wikilawyers.

Policy is harsh stuff, and there's a limit to how much people will hold in their heads. If you want an important process followed reliably, keep the guidelines and the reasons for them clearly separate from the hard bits. Set out how the few hard bits logically follow from the real hard policy.

Changing text on a project page won't change how people behave or what they think. (If only wikilawyers would realise this.)

Is this process good?

1. Does it follow logically from the core policies in one or two steps?
2. Can it be memorably summed up in one or two sentences, such that every element in the process follows logically from this summary?
3. Is it flexible enough to handle unusual and special circumstances?
4. Is it transparent enough not to create unnecessary strain on involved editors?
5. Does it show good common sense in general on the part of the Wikipedia/Wikimedia community?
6. Is the process so intuitive that a new editor could pick up on the process by seeing the process in action without ever reading the process text itself?

A really good process is one that Wikipedians don't realise is a process. The very best process is one that newbies don't realise is a process.

Hallmarks of bad process

All our process was created sincerely to do good. However, it may still have problematic results.

• Susceptible to being used to stifle debate or to intimidate other editors out of arguing on the ground that the results of the process are binding and cannot be reversed regardless of changing circumstances or understanding.
• Prescriptive when it could be phrased as a guideline
  • This actually reduces its effectiveness.
• Fails to assume good faith; excludes non-regulars who are unfamiliar with the complicated procedural decision making
  • Regulars assume bad faith or stupidity of non-regulars (other Wikipedians or anons) who do not understand process, and other regulars consider this acceptable behaviour.
  • Outsiders frequently complain of exclusionary process or ill treatment by regulars in the process; regulars are dismissive of these concerns.
• Process actions that are taken as personal attacks
  • If regulars keep having to say "don't take it personally" over and over and over, there's something deeply defective in the process that will be damaging to the encyclopedia project, even if you have a ready list of reasons why you absolutely have to do whatever the thing is people are taking personally.
• Works through a committee or inadvertent committee structure
  • Even ad-hoc committees can only work if they scale with editors and articles.
  • Forms an in-group susceptible to the above problems.
  • Has named offices, especially Director; Directors direct committees.
  • Any process with regular voting or straw-polls is susceptible to this. Exercise: Think how to fix the committee problem with AFD, DRV, RFA, FAC or the AC.

If a process is potentially good, but smart and well-intentioned people keep screwing it up, then it's a bad process.

You do not examine legislation in the light of the benefits it will convey if properly administered, but in the light of the wrongs it would do and the harms it would cause if improperly administered.

— Lyndon B. Johnson

Cultural expectations

These are the things we do that aren't actually codified. The feel of the project. The social structure. This stuff is process too, but if you contradict it you'll really upset people. Breaking a rule is just breaking a rule; but breaking a cultural expectation is breaking people's basic assumptions about the fabric of this small world of ours. And upset volunteers fade away.

If you think you're keeping to the fundamental rules and the sensible processes but repeatedly upset people in the same way, your approach is ineffective. If you are in fact right, and cultural expectations are getting in the way of writing the encyclopedia, you've got a hard job ahead of you changing them. But that's the trouble with vision.

How to deal with excessive or broken process

It's pretty much always in order for someone of clue to go "What on Earth?!" and cough up a hairball. Of course, they then have to convince others their intuitive leap is valid.

• Think: "How does this process help us write a neutral, verifiable encyclopedia?" If it doesn't, it should go.
• Assume good faith. The people defending a bad process are as sincere and dedicated to the project as you. That complete idiot is as sincere as you ... and they think you're a complete idiot too.
• If the processes prohibit you from improving the encyclopedia, Ignore all rules. You get to deal with the fallout, though.
  • If your only argument is Ignore all rules, you need a better argument.
• Think deeply on the actual problem. There's almost certainly a more elegant mechanism that does more with less.
• It's easier to show than to tell, but be ready to explain yourself in detail.
  • You'll have to convince other editors who think your solution is bad. Upsetting people may not be good, even if they're dead wrong; they're smart people of good will who don't see something you consider obvious. So show your working in full — you leapt from A to Z, but you need to set out B, C, D and so on for others.
• Not-quite-parallel lightweight processes can sometimes help. WP:PROD works well for WP:AFD, but WP:GA notably failed to work around WP:FAC's problems.
  • You need to convince the incumbents of the excessive process that the lightweight process is a good idea and will take load off them.
• You might just be wrong and have failed to understand the present process.
• Don't be a jerk. Really.

Approaches that don't usually convince

• Blow it up.
  • This doesn't work very often and is pretty much instantly reverted. See WP:POINT.
• Get the Arbitration Committee to blow it up.
  • This works even less often, unless the stupidity is really quite amazing.
• Get Jimbo to blow it up.
  • Note that the community frequently tells Jimbo to get knotted that they strongly disagree.
• Treat the rules as a game of Nomic.
  • You can't in fact implode the rules by turning them against themselves. See WP:LAWYER.

How to deal with a disregard for process

When encountering an editor who seems to be displaying a flagrant disregard for process, you need to convince them. Check the process for robustness.

• Show how the process follows as directly as possible from core policies. This is one of the best ways to resolve disputes over the value of a process.
• Do people keep complaining that it's hard to understand or that it excludes outsiders? Do regulars express distrust of non-regulars, or dislike the idea of any random person interfering? Then something needs fixing, even if ignoring the rule isn't the answer.
• Failing to follow or rejecting process is not, of itself, a wrong act. The encyclopedia itself is more important than any process designed to protect it. Judge intent and results against the core content policies and core community policies.
  • If your only argument is "it's out of process" or "it violates policy" (other than a core policy), you need a better argument. See WP:POINT.
• Changes in process may be sudden, or they may be gradual. An editor who consistently disregards a particular process may indeed influence others to do the same ... and that process is changed. Make sure the documentation stays up to date.
• Of course, the editor may well be a troll or a jerk. But don't make that your first assumption.

Approaches that don't usually convince

• Just quoting policy and guideline pages, especially using acronyms as verbs (e.g. "You need to AGF, NPA and NPOV yourself") — even when you're right.
• Defending the process while ignoring the situation.
• Defending the process out of process. This won't make disagreement, particularly from multiple editors, go away. They will be back.
• Using process to guide consensus. This forms a consensus of insiders (the "inadvertent committee") rather than being a good sample of Wikipedians. If you say "Wikipedians have formed consensus" and it was actually a seven-to-three vote on an obscure subpage somewhere, don't be surprised if people respond badly.

These approaches "work" in that they may drive off dissenting editors from the page or the project. This defends the process at the cost of damage to the project.

Note

We're here to write an encyclopedia — not to write rules on how to write one, or to write rules on writing those rules. This essay isn't those either.

The encyclopedia is primary, not writing and discussing rules and policies.

See also

• Wikipedia:Avoid instruction creep
• Wikipedia:Requests for process, humorous
• WP:NOT#Wikipedia is not a bureaucracy