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.)

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

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 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.)

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

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.

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.