Summary: fixing UseMod markup
< : "the content editing should be one with the goal
> "the content editing should be one with the goal
< : "I favor a major reorganization of the wiki material." – Neil Smithline (2011)
< : "The articles are littered with crappy advice confusing beginners, have little structure and are filled with ridiculous questions" – Bozhidar Batsov (2012)
< : "Wiki is a hydra you cannot cut enough heads off to make it die. I tried, and failed miserably. I suggest you don't waste your efforts
> "I favor a major reorganization of the wiki material." – Neil Smithline (2011)
> "The articles are littered with crappy advice confusing beginners, have little structure and are filled with ridiculous questions" – Bozhidar Batsov (2012)
> "Wiki is a hydra you cannot cut enough heads off to make it die. I tried, and failed miserably. I suggest you don't waste your efforts
< : "What I propose is starting anew and getting rid of a few common complaints at once." – wasamasa (2015)
> "What I propose is starting anew and getting rid of a few common complaints at once." – wasamasa (2015)
(TL;DR: People that don’t like the wiki as it is ought look at the official Emacs documentation instead. I wrote this so that I’d have something to link to in the future. This post was inspired by 2012-03-20.)
Every year or so, I read about suggested changes to the Emacs Wiki. The complaints are the same, year after year.
The solutions invariably have nothing to do with the problem.
Why are these suggestions not helpful?
The first problem is the mistaken belief that technology can substitute for social change. Yes, the wiki is badly organized and many of the pages are outdated. Changing the wiki engine, the backend or the formatting rules will not change this, however.
The backend used by the wiki engine can influence performance and resource use, it can make the software harder or easier to maintain and backup—but it will not induce somebody to edit a messy page and fix it.
The second problem is the mistaken belief that moderation can be commanded. You can complain about bad editing and a lack of moderation all day. But since nobody is paying people to do a boring job, we must rely on obsessive compulsive people to fix typos and tag pages.
Maybe we could attract more people by gamifying the experience—offer rewards, badges, scores. But Stack Overflow already does this. It’s the best social question answering machine currently known. The wiki doesn’t need to imitate something better. The wiki needs to do what it does best. We’ll come to that.
The third problem is the mistaken belief that quality control and volunteers go well together. Just compare Wikipedia and Citizendium and consider the animosity generated by Deletionism on Wikipedia. How will you encourage authors to contribute if you are telling them that their contributions are lacking the quality you are looking for instead of simply accepting their text and working on it?
You fight spam, you rework text occasionally, you encourage others, you welcome newbies, you lead by example. That’s how you lead.
An abrasive personality, radical change involving a lot of work—those are not the tools you are looking for.
Let me return to the issue of commanding change. Things people have said:
“the content editing should be one with the goal of creating a comprehensive, coherent, article that gives readers info or tutorial about the subject.” – Xah Lee (2008) “I favor a major reorganization of the wiki material.” – Neil Smithline (2011) “The articles are littered with crappy advice confusing beginners, have little structure and are filled with ridiculous questions” – Bozhidar Batsov (2012) “Wiki is a hydra you cannot cut enough heads off to make it die. I tried, and failed miserably. I suggest you don’t waste your efforts and time on that.” – Eli Zaretskii (2014) “What I propose is starting anew and getting rid of a few common complaints at once.” – wasamasa (2015)
The critics can be unhappy about it all they want, and they can complain about it all they want—but in the end, one needs to understand the forces at work, here. There is no chain of command.
It works just like a free software project. If it doesn’t scratch someone’s itch, nobody is going to add it. I think it’s a fundamental issue with our business model: there is no pay for boring stuff. Plus, documentation is of no direct use for anything—unlike code. Thus, people are mostly motivated to keep their own code and its documentation up to date. I don’t think there is anything we can do about that. That’s why the Emacs Wiki Mission Statement does not mention organization and quality. It cannot be commanded.
Once we accept that this is the sand upon which we are building our house, we necessarily need to scale down our expectations. Personally, I think the wiki exists somewhere between the official documentation, Stack Overflow, the FAQ, the newsgroups, the mailing lists, and IRC. It’s certainly nowhere near the quality of organization and writing that the Emacs documentation has—and I don’t think this is the right medium to aim for this level of quality. I think the people willing to invest that amount of energy to write quality stuff ought to be writing the real Emacs documentation—and they probably are.
What remains are the people using Emacs Wiki for their own pet projects, questions asked, answers given, sometimes organized, sometimes rewritten, sometimes linked to the rest of the site.
Wikipedia works because of its universal appeal. When I added an image to an obscure Indian temple we visited when I was staying in Mysore, the photo was terrible. But it was a start, and enough people cared about the page and it grew, and it found people to tend it, and now it’s big and beautiful.
There just aren’t enough Emacs users and authors out there and the best of us will be contributing to the official Emacs documentation. The wiki exists somewhere between the official documentation and the mailing lists. Lower your expectations.
Given all that, why does the wiki exist at all?
When I started it, I had several reasons:
I think this last point bears consideration: I was creating pages or adding information to pages because it was pertinent on IRC. An index, linking to the page, categorization, returning to the page later and reworking it, all these quality related tasks were not pertinent on IRC. All I needed was a pastebin that I could go back to and rewrite if I felt like it. Often I did not—and I still don’t.
The wiki being on the web, updated every now and then, with pertinent answers to specialized questions, unorganized and raw, ended up being a good resource for the search engines out there. These search engines bring new people to the site. People that don’t understand how wikis work in general and how this wiki grew to be where it is in particular. They are shocked. So many pages outdated! Such a mess in style and quality!
I think those people are better served reading the official documentation. They don’t want this mess, they don’t benefit from it’s loose rules, they don’t understand how cool it is to have a site with no login required. They are better served elsewhere.
I’m sure that one day the Emacs Wiki will have become irrelevant. But just like the old newsgroups never disappeared entirely, so will the wiki transform into something else and remain part of our information landscape.
Perhaps one of the Emacs Wiki critics will one day set up an alternate site, pull all the pages (more than 8500 pages last time I checked), extract the quality content—or rewrite it from scratch—and produce something better. Perhaps they will build an organization that can keep the quality up, encourage new authors to join, provide more value to their readers. But I don’t think complaining about the existing Emacs Wiki is a step in the right direction. Build it, and they will come—elsewhere.