User blog:Kjnoren/A tale of four power users

An attempt to discuss four different contributors to a wiki, who can all be reasonably described as power users.

The hacker

The hacker is a person of great technical skills and knowledge. They have a deep knowledge of the nuances of wikitext and parser functions, feel at home creating templates and infoboxes, can get around in CSS, and know either Lua or Javascript as it pertains to Mediawiki. They might have written their own custom bots or know their way around Semantic Mediawiki or Cargo. You will have to pry the source editor from their cold dead hands. When they receive new information, they ask if they can make a template based on it.

The publisher

The publisher is likely well-versed in wikitext and templates, and might know a bit of CSS. They are also good writers and have likely taken an interest in crafting the wiki rules and style guides. They might know how to run a simple bot for one-off jobs. They will find any grammar or typographical errors on a page, and fix them. They might have started out working with the visual editor, but know their way around the source editors too. When they receive new information, their first instinct is to work out where and how to add it precisely and appropriately.

The designer

The designer is concerned about making the wiki look as unique and interesting as possible. They will know a lot about applying CSS and how different design elements interact. They will try to set up advanced colour palettes or custom menus or galleries. They can be obsessed with custom fonts. When they receive new information, they will ask if it needs a custom style or presentation.

The completist

The completist is a topical expert. They have seen all the episodes, and know the major and minor events of each. They document the stats of every creature in the game. They create timelines, walkthroughs, and episode guides. Above all, they document everything, and nothing is too small to document. They may prefer either the source editors or the visual editor, but it's a tossup. When they receive new information, their instinct is to add it as soon as possible wherever it might fit.

What does this mean?

Let me first say that the four types above are highly stereotypical—most experienced wiki editors have a bit of each type, though in different levels. All the types can be highly beneficial to a wiki, but also needs to be applied in moderation. All four types can fall into the trap of perfectionism, though it will take different forms.

But the four types are also needed in different amounts. Most wikis need only a single hacker or designer in order to be kept up to date, since the files and areas they work on—CSS files, templates, modules, and JS—tend to be centralised in the wiki. Publishers work more widely, but their self-assigned role is more to check and improve the work of other people. But a wiki on a wide subject can never have too many completists.

But due to the way admins are selected and the extra privileges they have, there is an overrepresentation of hackers and designers with this role. By itself this might not be a problem, but it can be if their specific viewpoints on how to build and maintain a wiki comes to dominate. A sign of a good wiki design is one that will allow completists and publishers to contribute easily and meaningfully, doing what they do best: writing text and making links. Good admins should view themselves as enablers for other contributors.

To have a style guide is great, but it should not be so large and complex it is a chore to read. Nor should it be a requirements to read it, either in policy or in practice. Templates should be consistent in how they are used, findable, and easy to use. Mistakes should be fixed rather than punished. If a specific mistake is common, it should be viewed as a hint that something can be improved in the underlying design.

Wikitext was built with two goals in mind. It should be quick to write and be human-readable. Too much emphasis on general or multi-case—and thus complex—templates can get in the way of this. The wiki approach to redundancy is not to push the wiki into becoming a database, but to throw manpower at it.