Jump to content
Wikipedia The Free Encyclopedia

Wikipedia:Practical process

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by David Gerard (talk | contribs) at 13:50, 20 September 2006 (How to deal with a disregard for process ). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision .Revision as of 13:50, 20 September 2006 by David Gerard (talk | contribs) (How to deal with a disregard for process )
Essay on editing Wikipedia
This is an essay.
It contains the advice or opinions of one or more Wikipedia contributors. This page is not an encyclopedia article, nor is it one of Wikipedia's policies or guidelines, as it has not been thoroughly vetted by the community. Some essays represent widespread norms; others only represent minority viewpoints.
sandbox, draft, blah blah, feel free to add stuff, complain on talk; also needs to be half the length with the same amount of ideas.

title ideas: (none really work yet, but food for thought)

* (削除) Process is Dangerous (削除ここまで) * A practical guide to process on Wikipedia * Process is Perilous * Process? What Process?
* Process Mustn't Pessimize * Process Mustn't Ossify * Process, not Prescriptivism * Process, not Prescription
* Process is Only a Tool * Process is a Living Thing * Process is not a Way of Life * Don't Process For Its Own Sake
* (削除) Process versus Progress (削除ここまで) * Process and Progress * As Little Process as Possible; as Much Process as Necessary * Process Is Provisional
* Process on Wikipedia * Process creep * Process is a mess * Do not bless process
* Process, make your guess * Process: no or yes * Confess to process * (削除) Process, my - ah, never mind (削除ここまで)
* Fluid process makes solid content * Less process, more progress * If it's too hard, I can't understand it! * Fewer steps for greater distance
* Process is to serve, not to rule * Progress without process * Clue not glue * Practical process
* Process is not the point

Process is Important — or we'd all kill each other. Following process really will reduce confusion. But that doesn't mean more process is therefore better. Indeed, process is dangerous. It is added on the spot as needed, and must be culled at a similar rate.

Process is only a means to the ends that Policy spells out. Policy is semipermanent, but process is ephemeral (or should be).

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

The function of process

We're here to write an encyclopedia. Process is only there to help us write an encyclopedia.

Having no process means anarchy or chaos. Having too much leads to bureaucracy. We use process:

  1. To give some consistency in similar situations. This helps with FairProcess and reduces the need to revisit decisions due to shifting precedent.
  2. To reduce the redundant effort of making every decision from first principles.
  3. To encourage institutional learning and lead to a higher overall quality of decisionmaking.

If you follow policy and process, editors know which way is up today and don't feel the ground shifting under their feet. (Unless an earthquake is a good idea.) Be careful about cutting corners that people are standing on.

The foundation policies are neutral point of view and free content. en: adds as core verifiability and no original research. Our core community policies are assume good faith and no personal attacks. You should add Don't bite the newbies, since they seem to write most of the actual content.

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

How process is created

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, etc. These are ultimately all skins and mechanisms for poking at a Wikipedia that is too big to actually control.

Almost all our processes are quick hacks to achieve a temporary result — especially the fragile politicised compromises hammered out over much argument. They should be regarded as largely the bodgy hacks they are, to be thrown away when they are more trouble than they are worth.

The danger of process

Kudzu was invented to supply similes for process.

See m:instruction creep. Red tape grows. It must be pruned regularly, or it will cover everything.

People come along looking for the rules, so that they can do things the way we do things here, however that is. They see a quick hack that was actually built out of gaffer tape and string, but assume it is a polished stainless steel product of immaculate and well thought-out design. They then follow this process rigidly.

All our process is temporary scaffolding to help us write an encyclopedia. But there is an observed tendency to treat any aspect of process as received wisdom. Editors revert-war to keep someone from changing process, behaving as though anyone trying to fix a broken hack is acting in bad faith or is too clueless to be trusted.

Process exists to help clueful editors of good will work more efficiently, not to beat other editors with or cause internal civil wars. If it doesn't violate NPOV, NOR or V, it is preferable to bend, ignore, or create an exception to the rules than to cause a fight or a continuous series of fights. An exception does not destroy the policy, and can be quietly ignored later. Fights are always destructive, and difficult to ignore.

Excess process wears editors down and leads to volunteers disengaging from the project, which is direct damage to the project.

Complex process excludes outsiders

All our success has come from staying as open as we possibly can. If it's not easy to edit, it's not a wiki.

Wikipedia is not finished and we always need new editors — the available numbers appear to show that new and occasional editors, not the regulars, in fact write most of the content. It is important to Wikipedia that new editors not feel like they've fallen into a maze of bureaucracy. They need to be given a bit of leeway, or otherwise they will not add the content. Process that hampers the addition of content must have severe justification.

Experienced editors who habitually chastise new editors for not following process will be more effective if they assume good faith and suggest better ways to do things. Leaving hit-and-run templates on a talk page doesn't cut it. Don't bite the newbies.

Overworked regulars forming inadvertent committees

In some areas, the process is set up such that an ad-hoc group of Wikpedians will vote or discuss the matter. As the process page gains regulars, these can form into virtual committees.

However, committees cannot scale with the number of editors or the number of articles. The overworked regulars then tweak process to make the process page easier for themselves - formalised systems, local jargon and so forth. This excludes outsiders from the pages. Some will express open suspicion of outsiders, to protect the process from damage - even if it damages the project. (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.)

You can't legislate clue

Process helps good editors; it can't really stop stupid or malicious ones. The latter think a system is for gaming, and processes to stop this will be ignored by them or gamed further, while hampering the editors of good will. No rules can prevent stupidity, and no rules can prevent malice.

Process is not a substitute for common sense, and following process to the letter does not cover your ass in any way. In the pedophile userbox wheel war arbitration case, following process with no regard to good sense got several admins de-adminned for egregious stupidity.

Anyone who says "out of process!" may be forgetting this. Anyone saying "but I followed process!" should be referred to the abovementioned arbitration case and treated gently as someone who is sincere but doesn't understand yet. (Everyone reading this essay should read that arbitration case page and try to understand what happened and how, and why the ArbCom decided what it did.)

Is this process good?

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.

Hallmarks of good process

  • Follows in one or two steps from the basic policies
  • One-sentence precis.
  • Is intuitively obvious to non-regulars
  • Has wide acceptance
  • ...
  • 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

  • Fails to assume good faith
    • Regulars assume bad faith of non-regulars (other Wikipedians or anons), and other regulars consider this acceptable behaviour
    • Regulars assume stupidity or lack of deep understanding on the part of non-regulars, and other regulars consider this acceptable behaviour
    • Outsiders frequently complain of ill treatment by regulars in the process; regulars are dismissive of these concerns
    • Tries to force participants to prove good intent
  • Excludes non-regulars
    • Non-regulars often complaining of exclusive process
    • Regulars frequently assume bad faith or lack of understanding on the part of outsiders who complain of ill treatment
  • 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
  • Prescriptive when it should be a guideline
    • Some people think that making hard rules means others will then follow them. This means editorial guidelines get phrased as didactic policy. This results in stupidity such as WP:RS (a guideline) being used by apparently insane robots as a reason to gut articles of content. In perfect sincerity.
    • Policy is harsh stuff, and there's a limit to how much people will hold in their heads. Everything that can be a guideline should be, because clueless editors won't understand it and bad faith editors won't care.
    • No-one reads the whole Manual of style. I haven't and neither have you. As prescription, its only purpose is to beat other editors over the head with. If you need a Taylorised guide, you wouldn't understand it if you had it.
  • ...

How to deal with excessive or broken process

It's pretty much always in order for someone of clue to go "What the hell?!" 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.
  • 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 have no argument.
    • If other editors have good reasons your solution is a bad idea, IAR is unlikely to be enough.
  • Think deeply on the actual problem. There's almost certainly a more elegant mechanism that does more with less.
    • After you've come up with the more elegant mechanism, you have to convince people.
    • Just because it's intuitively obvious to you doesn't mean it is to anyone else. 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.
  • It's easier to show than to tell, but be ready to explain yourself in detail.
  • Not-quite-parallel lightweight processes can sometimes help.
    • WP:PROD works well handling the simple stuff for WP:AFD and has made AFD much nicer (though the process is still Byzantine).
    • WP:AFU may take on the merit-related undeletions that the incumbents of WP:DRV refuse to allow that page to consider. Or DRV may expressly expand its remit to merit again. We'll see.
    • WP:GA notably failed to work around WP:FAC's ever-increasing requirements, rapidly becoming as difficult to get through.
    • 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 dick. 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.
  • This isn't Nomic. You can't in fact implode the rules by turning them against themselves. Trying to do so usually results in the creation of an additional rule.

How to deal with a disregard for process

When encountering an editor who seems to be displaying a flagrant disregard for process, check the process isn't flawed.

  • Rewrite the process description to show how it follows as directly as possible from core policies. Even if it isn't made official, this helps you explain it to others better. This is one of the best ways to resolve disputes over the value of a process.
  • Reexamine the process. Does it follow obviously from the core policies? 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?
  • 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. Measure both intent and results against the core content policies (NPOV, V and NOR) and core community policies (AGF and NPA).
    • If your only argument is "it's out of process" or "it violates policy" (other than a core policy), you don't have an 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 dick. But don't make that your first assumption.

Approaches that don't usually convince

  • Quoting policy and guideline pages, especially using acronyms as verbs (e.g. "You need to AGF, NPA and NPOV yourself.")
  • 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.

Notes

...

Process should not be erected as a hoop to jump through.

We are here to build an encyclopedia — not to create rules on how to build one.

...

See also

AltStyle によって変換されたページ (->オリジナル) /