Mediawikianism

From Meta, a Wikimedia project coordination wiki
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[edit]

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[edit]

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[edit]

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".[1] 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.[2]

See also[edit]

References[edit]

  1. Dash, Anil (7 May 2010). "One More Time: No NDAs". 
  2. Komissarouk, Alexey (15 April 2012). "Stop Looking For A Technical Co-founder". TechCrunch. Most quality software engineers today have offers of amazing work environments and 6-figure salaries from the likes of Google and Facebook. Few are crazy enough to say no to that. Those that do typically have their own ideas, aren’t sure they need you, and have heard enough cliche pitches to ignore you by default.