Mediawikianism

Wikimedian philosophy

Community

Anti-wiki

Conflict-driven view

False community

Wikiculture

Wikifaith

The Wiki process

The wiki way

Darwikinism

Power structure

Wikianarchism

Wikibureaucracy

Wikidemocratism

WikiDemocracy

Wikidespotism

Wikifederalism

Wikihierarchism

Wikimeritocracy

Wikindividualism

Wikioligarchism

Wikiplutocracy

Wikirepublicanism

Wikiscepticism

Wikitechnocracy

Collaboration

Antifactionalism

Factionalism

Social

Exopedianism

Mesopedianism

Metapedianism

Overall content structure

Transclusionism

Antitransclusionism

Categorism

Structurism

Encyclopedia standards

Deletionism

Delusionism

Exclusionism

Inclusionism

Precisionism

Precision-Skeptics

Notability

Essentialism

Incrementalism

Article length

Mergism

Separatism

Measuring accuracy

Eventualism

Immediatism

Miscellaneous

Antiovertranswikism

Mediawikianism

Post-Deletionism

Transwikism

Wikidynamism

Wikisecessionism

Redirectionism

+/-

Mediawikianism is the philosophy that holds that most of the problems that occur on Wikipedia and its sister projects can be solved through improvements to the software. The software is often overlooked as the all-important glue that holds the project together. There were, after all, Squid servers and people willing to contribute content for free before Wikipedia's founding in 2001, but what enabled Wikipedia to really pick up momentum was the software and the openness that was inherent in its design.

Many of Wikipedia's most difficult problems have been addressed through software improvements. Some pages were almost impossible to edit before gadgets like wikEd were developed. Inline referencing was a nightmare before Cite was implemented. We also have many more vandal-fighting tools in our arsenal than we used to. It became possible to reach a compromise between protection and unprotection when semi-protection was introduced. Often an ingenious software improvement is like a sword that cuts through the Gordian knot of debate about a decision or policy.

Policy has largely stagnated because it is so hard to find consensus for any major reforms. The archives of debate on many perennial proposals are voluminous, reflecting the consumption of many editors' time, usually to no avail. But one developer can contribute a software feature whose demonstration (perhaps on another wiki) may change people's minds and alter the future of the wiki. It is said that editors matter. They do, but a good developer can make more of a difference than a good editor. Editors are relatively plentiful, while development talent and a willingness to put in the hard work necessary to contribute quality code are comparatively scarce. For evidence of this, compare the time spent producing the talk page archives at w:Wikipedia talk:Pure wiki deletion to the amount of time spent producing code to allow its implementation.

The Association of Mediawikianist Wikipedians salutes all those proud 20 percenters who toil behind the scenes to create the core patches and extensions that enable collaboration among all the other members of the community. Users with an interest in software development are encouraged to consider becoming a MediaWiki hacker. The codebase is large, complex and seemingly daunting at first, but with tenacity and ingenuity, it is possible to become a successful developer and change the world for the better.

The Bugzilla principle

Users should be encouraged to take their MediaWiki suggestions to Bugzilla instead of debating the merits of a software enhancement at forums like Village Pump Proposals. The reason is that these forums tend to be overrun by idle speculation, "what-ifs," and resulting conservatism rather than a can-do attitude toward fixing the issue, and the debate is less focused on making concrete steps toward issue resolution and closing cases and therefore can result in much wasted time. Further, key people like Brion and Tim are usually not present at those forums. And updates to those discussions do not get emailed to interested parties and posted to IRC, which prevents the usual prodding of people to get involved. Old Village Pump threads usually just get archived and forgotten; there is no convenient cross-linking of duplicate bugs, easy searching of archives for particular bugs, etc. If a proposal goes nowhere and gets archived, when it gets brought up again, the whole conversation usually has to be renewed from scratch; it can't just get WONTFIXed and then reopened, with automatic notification to all the formerly interested parties (because to notify them would be frowned-upon canvassing, on Wikipedia).

Bugzilla offers a more elegant mechanism for promoting good ideas and weeding out bad ones. If no one feels like devoting the time needed to fix something, then the proposal dies a natural death. Kind of like how in the marketplace, the real test of whether a product is worth producing is whether customers are willing to shoulder the cost of production by purchasing it, often the best test of whether an enhancement is worth implementing is whether anyone cares enough to actually sit down and write the code. If they don't, then nothing we say at the Village Pump can implement it. On the other hand, if someone wants to implement it, and they don't mind putting in the time to do so, and it's not a harmful change, then who are we to say that it's a waste of time?

Developers are one in a million

There is probably about a 1:1K ratio of developers to editors, and a 1:1M ratio of developers to readers. (This is assuming one defines a reader as someone who has read Wikipedia in the past year, an editor as someone who has edited in the past year, and a developer as someone who has committed a revision to SVN in the past year. There are 143 such devs, and probably 143,000 such editors, and probably 143,000,000 such readers.) It's not hard to see why:

• Development involves a lot bigger learning curve than editing, because the codebase is vast and unfamiliar, while an editor may arrive to the encyclopedia already being a subject matter expert in whatever he is going to write about. Editors have to learn policies and guidelines, but devs have their own coding conventions to get used to.
• The software developers work with (PHP) is a lot less user-friendly than the software editors work with. Compare "Sorry! We could not process your edit due to a loss of session data. Please try again." to "Syntax error, unexpected T_OBJECT_OPERATOR"
• There is a lot more documentation available for software users than for software creators. (The Wikipedia namespace is a lot bigger than MediaWiki.org)
• Assistance is more forthcoming for software users, because their problems are simpler and have been dealt with before. If you get stuck trying to figure out how to do something with the software, it's probably a lot easier for someone to help you in your capacity as a user than in your capacity as a developer.
• You either produce working code or you don't; halfway measures don't work. In contrast, you can write a halfway decent article and it will still be somewhat useful; and another editor can easily pick up where you left off. Development requires more continuous effort, and due to the need for debugging, and the potential for unexpected interactions with other code to occur, one never knows how long it will take to produce working code; editing, on the other hand, can be squeezed into small periods of idleness in one's schedule.
• Development requires more concentration than editing because the software is written in computer code, rather than one's native tongue, or indeed any other language that was designed for human communication. Humans have evolved over millennia to communicate with one another; computer languages have only existed for decades. Thus, the ease-of-use of these languages is about at the same stage of development as cuneiform script. It's more like solving a mathematical problem than communicating with another entity; if you get interrupted in the middle, you may have to start back at the beginning to figure out what you were doing.

It's all about the commits

“ ...the only truly important product of the system development process is code – software instructions that a computer can interpret. Without code, there is no working product. — Coding ”

Allison Randal writes, "One line of working code is worth 500 of specification." In Junta or in Weakest Link, money doesn't count till it's banked. Likewise, in programming, your ideas don't count until they're coded. Computers don't execute ideas; they execute code. As Anil Dash points out, "good execution is hard to find, but good ideas are cheap". Write that code, test it, and commit that baby! If you get hit by a bus tomorrow, all that matters is what you put in the git repository. No one will ever look at the ideas you posted to some wiki page, and left for someone else to implement; and no one will finish your half-written code that doesn't run. Good programmers typically have so many ideas of their own that they want to implement that they won't get around to doing your coding, certainly not without pay.

See also

• Category:Mediawikianist Wikipedians
• en:Category:Mediawikianist Wikipedians
• mw:Developer hub
• en:Persuasive technology