User:Electrawn/Process is Good

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 and must be culled regularly.

"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

Process is a means to an end only. Product is more important. We're here to write an encyclopedia.

Byzantine process excludes newcomers

Wikipedia is not finished and we always need new editors. It is important to Wikipedia that new editors not feel like they've fallen into a Kafka story — because the numbers show that occasional editors, not the regulars, in fact write most of the content. Process is for dealing with content; process that hampers content, and those who add it, must have severe justification.

Ossification

Almost all our processes are quick hacks to achieve a temporary result — especially the fragile compromises hammered out over much argument. Taking them as gospel to be preserved is fundamentally erroneous. They should be regarded as largely the bodgy hacks they are, to be thrown away when they are more trouble than they are worth. This is why Ignore all rules is policy.

Wikipedia has gotten big enough that people try to create policies and procedures to manage it. These don't really change it — Wikipedia:Counter-Vandalism Unit didn't end vandalism, Wikipedia:Proposed deletion (PROD) didn't fix deletion, etc. We hardly ever make changes that fundamentally affect Wikipedia's function; Wikipedia:Biographies of living persons was the last big one, and that was arguably just a particularly severe application of Verifiability, NPOV and No Original Research.

What we do instead is make procedures that allow the streamlining of one way of using Wikipedia. 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. Ultimately, these are all skins and mechanisms to prod at an increasingly too-big-to-actually-control Wikipedia.

The danger of process

See m:instruction creep.

People forget that process is temporary scaffolding for one purpose only: writing an encyclopedia. There is an observed tendency to treat any aspect of process as received wisdom, rather than the quick hack or fundamentally unsatisfactory compromise it was. They will 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.

Wikipedia's editorial process has become like a piece of open source software with no version control: a mess of patches that work great for their creators, and no one else.

Wikipedia is not "all about process" and such an attitude is absolutely contrary to our longstanding community spirit. Wikipedia all about people, about mutual respect, about thoughtfulness and respect for others as individuals. The rules lawyers of Wikipedia are a sickness upon us.--Jimbo Wales 16:20, 31 January 2006 (UTC)[1]

Good sense beats process

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 above mentioned arbitration case and treated gently as someone who is sincere but doesn't understand yet.

How to deal with excessive process

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.
- AGF is hard policy.
- But remember that "assume good faith" also means "never assume malice when stupidity will suffice." Then grit your teeth harder.
Ignore all rules.
Think deeply on the actual problem. There's almost certainly a more elegant mechanism.
- 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 all working. (US: "Show your work".)
Not-quite-parallel lightweight processes can sometimes help, e.g. WP:PROD handling the simple stuff for WP:AFD; WP:AFU doing the merit-related undeletions that the incumbents of WP:DRV refuse to allow it to consider.
- You need to convince the incumbents of the broken process that this is a good idea.
m:Don't be a dick. Really.

Approaches that don't usually work

Blow it up.
- This doesn't work very often.
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.

Notes

...

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

Having too much process results in a stagnant quagmire, stultifying the project.

We should remember to assume good faith, not forcing editors to sign loyalty oaths or otherwise prove good intent.

We should remember that a wiki is, by definition, supposed to be quick and easy to edit.

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

...

Process is important on Wikipedia, and to Wikipedia. Some people minimize the importance of process, using such slogans as "Product over Process" or "Ignore All Rules". But process is essential to the creation of the product. Process is a fundamental tool for carrying out community consensus, and for allowing a very large number of people to work together on a collaborative project. Process is also the mechanism by which users can trust that others are playing fair, that the rules do not suddenly change, nor are they different for some privileged editors. Poor process or no process ultimately harms the product.

There are many different processes on Wikipedia. These include the various deletion, speedy deletion, and deletion review processes; the various dispute resolution processes; the Request for Adminship process; various processes for policy formation and alteration; and the Featured Article candidate process. There are processes more specific to particular areas of Wikipedia, such as that for proposing stub types, and processes internal to various wiki-projects. There are also more informal processes such as those that happen in discussion on a particular article's talk page, when content or format for an article can be settled among the interested editors.

Most of these processes depend on community consensus in some form. Some of them ultimately rely on votes, or something like votes, to determine that consensus on a particular issue. But even during a "vote" most of them not only permit but encourage discussion in addition to simple "Yes" or "No" votes, in hopes that people of one view can persuade those of another, or that a compromise can emerge, and in either case a true consensus, not just a majority or super-majority, can emerge.

It is no accident that the basic mechanism for protecting civil rights in the United States is called "Due Process of Law". Indeed, in most governmental systems the effective mechanisms for protecting rights and freedoms are essentially procedural ones. Of course, Wikipedia is not a government, nor is its primary purpose to be a social or communitarian experiment. But many of the same problems arise whenever lots of people interact, some of them with strongly opposing views. The basically procedural methods that have been used to solve these problems when running governments often must apply, with suitable variations, in a project such as Wikipedia— and this only becomes more true as such a project becomes larger and more influential.

Sometimes a process can be a pain in the neck. Some processes demand that editors go through several steps to achieve a result. Some can be cumbersome or time-consuming. Some do not deal with particular situations as rapidly as a person might wish. Sometimes going through the process seems unlikely to give the result that a person desires. In all these cases, there is a temptation, sometimes a strong temptation, to act unilaterally, to simply "fix" the problem as one sees it. Often this is technically possible on Wikipedia. Sometimes many people will support it.

The problem with yielding to this temptation is that it damages the overall structure of Wikipedia. It throws sand in the gears of the project. When people see others acting outside of process, they may be convinced that they ought to do the same; or they may be convinced that their individual voices and views will get no respect or consideration. If everyone acts outside of process, there is no process, no organization to our efforts. Then we do not have a collaborative project; we have an anarchy.

An ordered collection of data. Authors unknown, but probably not spontaneously created by a football crowd.

The primary goal of Wikipedia is to write an encyclopedia, and any process is only a means to that end. Even the community of Wikipedians, important as it is to some, is only a means to that end. Often following a process takes more time and effort in a particular case than acting unilaterally. Sometimes following a process will give a poorer result in a particular case. But fairly often acting outside of process causes strong and widespread dissatisfaction, which consumes far more time and effort than any saved by avoiding the process in the first place. Even in the more numerous cases where no great uproar results, actions outside of process still tend to damage the trust of individual editors and users in the institution of Wikipedia, and to damage the community. And the community is the essential tool in the writing of the encyclopedia. Without the community, there is no one to write it, and there is no way to organize the writing. Without the community, there is no reason for anyone to undertake any of the many needed but unglamorous tasks on which the creation of the encyclopedia depends.

Process need not be inflexible— most Wikipedia processes and policies can be changed if the community, or the relevant section of it, wants to change them. Many processes allow for exceptions or alternate routes in particular cases or circumstances; such exceptions can be added to processes that do not have them.

In a small group there is little need for structure or process. When five people work on a project, little structure and no formal process may be required. When five thousand work together on a project, there must be some structure or the project will collapse. While Wikipedia intentionally has relatively little structure, it must have some to continue in a productive way. Processes, formal and informal, are some of the key elements in that structure.

During the early days of Wikipedia, few processes were needed to maintain its essential structure. Many— at first most— contributors knew each other or rapidly came to know each other. Issues could be resolved by informal discussion, with little need for any other process. As Wikipedia has grown, more process has developed. While many contributors still know or know of each other, there are many overlapping sub-communities, and no one knows all or even most of the major contributors. People have strong and differing views about policy and content issues. Process, often formal process, is needed to allow issues to be resolved in ways that all can accept as reasonable, even when individuals strongly disagree with particular results. Unilateral action tends to subvert that acceptance, and lead to a "me-first" or a "my way or the highway" attitude to the project— even or especially when people sincerely believe that they are acting for the good of the project.

Action outside of process is particularly dangerous when it involves powers restricted to administrators, or knowledge available only to long-established editors. This tends to create at least the impression of a caste system. No one wants to be on the bottom of a caste system, and such perceptions reduce the motivation for people to contribute.

For all these reasons, editors and particularly administrators ought to adhere to and use existing processes, and resist the temptation to act outside of process, other than in truly emergency situations. If a process is not good, think enough of fellow Wikipedians to engage the problem and propose a change to it; don't just ignore the process.