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. |
This page in a nutshell: Process should be followed if at all possible – not following it tends to harm the project, even if the result is unchanged. |
Process is important on Wikipedia, and to Wikipedia. Some people minimize the importance of process by pointing to Wikipedia policies such as "Ignore all rules" and "Wikipedia is not a bureaucracy" or other Wikipedia essays such as "Product over Process" or "Snowball clause". 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, and that the same rules apply to all editors. Poor process or no process ultimately harms the product.
There are many processes on Wikipedia. These include such Wikipedia official policies as those that specify the 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 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 chaos.
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 productively. 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.
On the contrary, if you follow policy and process, editors know which way is up today and don't feel the ground shifting under their feet. Perhaps ironically, following through with policy creates a transparent, and less eventful ride than pursuing a quick solution to everything. Accommodating transparency allows any interested party to review all the relevant evidence and reduces confusion by enabling anyone to independently verify whether the ultimate decision was reasonable by community standards. Reducing confusion enables editors to focus on important tasks instead of having to spend time justifying their actions to others.
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.
See also
edit- Wikipedia:Practical process – how to make process that can be followed
- Wikipedia:Processes – the patterns and the methods of routine and semi-routine actions
- Wikipedia:Requests for process – a satirical page about creating processes
- Wikipedia:Fruit of the poisonous tree § Wikipedia processes – discusses a consequence of ignoring process
- Wikipedia:Alternatives to ignoring all rules
- Wikipedia:Settle the process first