in praise of details

I was demo-ing the parts of a Wikipedia article the other day, to a group of people who wanted to learn to edit. There’s a lot to say about the external structure of an article on Wikipedia: the talk page, the history, the sidebar links. And a lot of this structure and its full implications don’t really register until you’ve been at it a while. Unpacking the page history, for instance, and how the wiki’s revision history makes what we do as editors really possible — the idea that a revision is a discrete item that shows up lots of places, like recent changes and your watchlist and the history, and that it contains several nuggets of information that you can use to understand the development of a page — this is an idea that takes a while to get a handle on.  I  still marvel at the general elegance of the system, even after all this time, but I don’t expect to be able to fully convey that to brand-new users.

What I did notice that these folks found especially cool were the details that I showed, the small add-ons that have grown up over the years that make neat things possible. An example: there’s a link to Henrik’s site from the English Wikipedia article page history, so you see at a glance how many times the page you’ve been working on has been viewed. To the best of my knowledge, it just appeared there, no doubt after a community discussion somewhere, about a year ago. My students thought it was amazing. When you go to edit an article, there’s the ref toolbar — pop in a doi or ISBN and it autofills template fields for you. Look on the left-hand sidebar, and now above the interlanguage links there’s a link to Wikidata; this is new this fall.

There’s this notion that we haven’t updated Wikipedia’s interface in years, and while it is true that major core elements look the same as they did last year  or a few years before that, there are small changes all the time on Wikipedia. There are features coded, tested, added, integrated, taken away. This is large part thanks of course to our endlessly creative volunteer editor/developer community, who are the masters of the small hack.

This is what being an open platform, and open software, means. These many small tools and hacks are not, of course, a substitute for the long-range software maintenance, planning, and improvement that the WMF and developer community do — but they are part of what makes Wikipedia delightful, a never-ending source of small discoveries and things that ease the way. We could improve many things about this volunteer developer process, of course — we should make sure features that got widely used by acclamation get steady support and perhaps get built into core, and make sure that all language wikis have access to the same suite of interesting and experimental features, and make sure that volunteer-contributed code gets reviewed and mentored well. But I am still impressed by what we have done so far.

I am not a developer, and never have been; my hacking is limited to modifying a few templates, a little CSS. But I am always delighted with how inventive people are with the Wikipedia platform, whether it’s tweaking their own userpage to do ridiculous things (I’ve seen everything from scrolling purple waves to making a sidebar overlay) or whether it’s building a new citation tool, which makes it easier for everyone to fulfill a core policy of Wikipedia. This is not something you can do with, for instance, Facebook; I use Social Fixer, which is a kind of overlay via browser extension for Facebook that users can install to make the default interface behave differently, and the developer of that tool was threatened with having all of his access rights to the API (and his own account) revoked if he didn’t make changes to suit Facebook’s advertising model.  In Wikimedia, we say to would-be ad-hoc developers: don’t break things, don’t screw up articles; otherwise, have fun, and oh, let us know if you have ideas for solving this bug.

This is similar (though not quite the same) as the way we treat editing articles — articlespace, as it’s generally known, operates under a fairly fixed umbrella of core policies and secondary guidelines that have grown up over the years, and that serve to make Wikipedia as useful as it is. Stay neutral. Don’t add false information; back things up with good citations to solid outside sources; don’t promote yourself.  For that matter, use an encyclopedic tone, add a good lede section, make sure you represent a worldwide view of the subject. These are editorial rules, and they need to exist to make Wikipedia what it is.  These policies generally hang together, and at least in their core form are relatively simple to follow once you get the hang of things. My class understood them right away, and settled down to make their first edits (“look, I added a reference!”) which was deeply satisfying to all involved.

I love to edit; I have since I discovered Wikipedia, and I expect I will enjoy it for a long time to come. As someone who spends much of their professional and personal time thinking about various aspects of Wikimedia and Wikipedia, I find editing to be like a break: something I do for fun. Like most veteran editors, I have a to-do list of articles to work on as long as my arm. (Though sometimes, I just settle down with a movie and index Commons photos or add Wikidata fields, for some brainless but productive multitasking relaxation time).

But when I think about what I find magical about our projects, and what fuels me to keep talking about the project, to keep advocating for it, to keep teaching it and trying my best to make it better — it’s the inside structure of Wikipedia and our projects: the endless project pages, small tools, little detailed additions that people come up with year after year — that gives me true delight. For instance: a while back, the geocoding template was developed, and suddenly after a little editing frenzy all geographic pages had their coordinates displayed in the corner. Then, someone at the WMF built an app to take advantage of this, to tell you what articles were near you. I used it when I was in Paris last year, obsessing over which of the thousands of landmark articles near me I could edit. Years ago, I remember when HotCat was ported over from Commons, and it felt like a miracle to be able to categorize with ease. These are details, small things, but they add up.

I cannot end a post like this without mentioning Magnus Manske, who has a day named after him in Wikipedia lore, and who is the unassuming black belt of this kind of hacking. Magnus’s tools are everywhere, in Commons and Wikipedia and the other projects, and he’ll whip things up for you if there’s a need. His ability to contribute both makes this project work better and serves as an example of the benefits of openness.

This is why I keep teaching Wikipedia, too, not just because we need more editors (though we do!) and not just because I want people’s expertise to be shared (though I do!) and not just because articles need improvement, and many more eyes. It is because in so many dimensions — and this is just one of them — the Wikimedia projects and how they work are inspiring, and I want to share that.

This entry was posted in "How Wikipedia Works", free culture/free licenses, wik-eh-pedia. Bookmark the permalink.