Problems of Emacswiki (2008)

The Emacswiki [http://www.emacswiki.org/ ], started by Alex Schroeder sometimes in 2005 or before, is great. However, i think it could've been better.

(1) The wiki software used is Oddmuse, which is a Perl script of 4k lines, using flat files as database. As such, it is not comprehensive or powerful.

(2) The content, is kinda haphazard. It is somewhat in-between of a encyclopedia-style treatment like Wikipedia and a chaotic online forum. Specifically, when you visit a article, half of article will be dialog between different users on tips or issues or preferences.

I commented to Alex about these problems. I suggest that it should use the same software Wikipedia uses, the MediaWiki. So that, it is far more powerful, with large scale programer support, and the user interface for the wiki will be one that's widely known to millions of users world-wide. (note: https://en.wikipedia.org/wiki/Oddmuse is something written by Alex himself, a pet love of sorts.)

I also suggested that the writing guidelines should follow Wikipedia's style. Specifically, the content editing should be one with the goal of creating a comprehensive, coherent, article that gives readers info or tutorial about the subject. (as opposed to, serving partly as a online forum between emacs users and maintaining dialog integrity)

I think there's a lot potential to Emacswiki. It could, for example, develop into a comprehensive elisp library archive (For example, CPAN). Listing packages by category, with each package come with a article that discuss its author, purpose, status, caveats, tutorial, similar packages …etc. And the packages need not just be modes… but libraries as in most languages. (for example, js2 and nxml modes are both complete parsers for JavaScript and XML, each over 10 thousand lines of elisp code. They should actually be several libraries, so that these parsers can be widely deployed as language modules, not confined in use just in one editing mode. Such is largely not done in emacs/elisp community due to emacs being primarily a text-editor with relatively few elisp programers… but is slowing happening anyway (it is something that eventually must happen). A good wiki can be great help in ushering necessary improvements and increase the speed of evolution.)

For the above to take shape, the wiki must adopt a style so that articles aim to be a coherent treatment of the subject (as opposed to dialog and random tips). (and this is done by crafting the contribution guidelines or rules; exemplarily done by Wikipedia) Also, i'd think the wiki's software should adopt something widely supported such as MediaWiki, as opposed to one-man's pet project.

Notes:

Wikipedia has been the world top most 10 visited site since about 2005. [see http://www.alexa.com/site/ds/top_sites?ts_mode=global]

«Wikipedia receives between 20,000 and 45,000 page requests per second, depending on time of day.» — Wikipedia

«English Wikipedia reached 4,000,000 registered user accounts on 1 April 2007» — English Wikipedia

WikiMedia has a user base of few million times more than OddMuse. The familiarity of users is important when it is of that magnitude. Similarly, tools that works with MediaWiki is some hundred times more, in various computing langs, than OddMuse.

For a indication of scope and breadth of Wikipedia, see: Lispers and Wikipedia, 2007, Links To Wikipedia from XahLee.org.

The following is a excerpt of a dialog between me and Alex Schroeder (emacswiki creator), in “gnu.emacs.help” on 2008-10-23, thread “Emacs Wiki Revision History” ( http://groups.google.com/group/gnu.emacs.help/browse_frm/thread/a62f24e5707a91e2).

Xah Lee wrote:

(2) The content, is kinda haphazard. It is somewhat in-between of a encyclopedia-style treatment like Wikipedia and a chaotic online forum. Specifically, when you visit a article, half of article will be dialogs between different users on tips or issues or preferences.

Alex Schroeder wrote:

Indeed, I agree with this statement as well. But that is as it should be: The wiki is broken as specified in this respect. What follows is a short rant on what the Emacs Wiki is and is not. ☺

Alex Schroeder wrote:

For Emacs, I don't care about a perfect wiki that can replace the manual. Emacs is and remains the self-documenting editor. As such, the good stuff, the well explained stuff, the carefully thought out stuff, the edited and checked stuff should go into the manual — either the Emacs manual, or the Emacs Lisp Manual, or the Emacs Lisp Introduction. I don't care. When I set up the wiki I was frustrated with how slow the FAQ was changing and the endless repetitions on the newsgroups and mailing lists. That's where the wiki fits in: It changes faster than the FAQ, it has less repetitions than the newsgroups and mailing lists, but it is not as structured and honed as the manual is.

Now the emacswiki has been there for a while, we can think how to make it better and work toward that goal, as opposed to what the original intention was.

Alex wrote:

Comparing it to the Wikipedia, where the wiki is the real thing, or to the Emacs manual, is a no-brainer. Of course it doesn't compare. But it doesn't have to. The wiki is in a separate category.

And of course the Emacs Wiki has the benefit of letting other people put their text where their mouth is: If people like Xah feel that the text of the wiki is lacking in quality, feel free to step up and work on it. Just like Free Software, complaining is far less effective than doing.

Criticism is not complaining, and even complaining is a significant form of contribution when done naturally. A significant contribution of major philosophers to society throughout history, is to criticize or complain. “Complaining” is not necessarily inferior to “doing”. A healthy, prosperous community, needs both.

In the tech geeker's open source community, there's a major problem of the mindset of “contribution”, where almost anything less than code contribution is deem by tech geekers as wanton bitching, especially when it arose in a online discussion turned quarrel. This “contribution” mindset does lots of harm to the growth and progress of open source community. To various degrees, it lessens the power of discussion, spur forking of projects, duplication of coding effort, proliferation of less quality code. (See also: Responsible Software Licensing, Criticism versus Constructive Criticism. )

For example, why do you fork UseModWiki in the first place? In some tech geeker's sense, you are reinventing the wheel.

If i quietly grabbed your emacswiki content (which is perfectly legal and guaranteed a right under FSF associated licenses) and shape it in the way i think is proper (i.e. using MediaWiki), effectively a fork, such deed is often controversial as you must know, and often it spurs animosity among groups and create factions.

Whether forking in general does good or bad to society, is a complex issue and there is no simple answer. When philosophies and vision or methods between developers differ significantly, forking is probably the only recourse. And such forked project contribute diversity (For example, BSDs; Linux distros), and sometimes ultimately determines which is better one, or may spur major change that otherwise will not come (as XEmacs did to GNU Emacs). But on the other hand, sometimes forking is merely a result of political animosity. (For example, “somebody else's” project vs “My” project.)

I can, and i might, take your blessing and create a alternative emacswiki, or even consume emacswiki.org with your help. That takes a lot dedication, time, and some money to do it. As i mentioned, MediaWiki interface is familiar to some one hundred of thousand time more users than OddMuse, and there are perhaps hundreds times more tools to work with MediaWiki than OddMuse. With MediaWiki, you also automatically have a lot features, such as images, math formula formatting, playing audio, citations system, category, syntax highlighting, multi language support, each of these far more robust and rich than OddMuse if it support it. Many of these features are seemingly not much useful for a wiki for emacs, but you'd be surprised what people do and how things grow. (for one example, emacs wiki could use lots of screenshots, and when done a lot, you'll eventually need MediaWiki's image annotation, citation, permission features)

One reason you cited against MediaWiki is that it's rather difficult or complex to install. I agree OddMuse is far more easier to install (being just one single Perl file). However, you are a expert in the Web App field, and so am i. For a web app professional, to install MediaWiki, with its associated database etc, isn't that hard. Even i haven't done so, i think you'll agree, that it takes within 1 week man hour to install it with all content transferred from emacswiki.

As you detailed, OddMuse is pretty much just your pet project. That and its simplicity is pretty much the reasons you use it for emacswiki. As project gets large, this cannot be remain so without hampering the growth of a wiki for emacs.

Alex wrote:

The only thing I will oppose very strongly is the setting up of guidelines and requirements and all sorts of foolish rules, because that doesn't improve the text. It just prevents other people from posting. Way to go, social skills.

I think some guideline is sufficient. The gist is that, someone needs to provide that guideline, or give a indication that coherent article is the goal as opposed to maintaining a conversational integrity of wiki editors. In this case, that someone should be you, because you are the original creator and thus most suitable and authoritative.

This guideline or indication is important. For example, sometimes i thought about cleaning out the discussion-oriented content … which usually means simply delete them. However, without a authoritative guideline, that'll raise a lot problems. People will revert it, ask why you delete them, considering it removal of record, resulting quarrel or unease, or even consider it absolute vandal.

I being already a controversial figure. As you know, i've been ban'd in freenodes's irc on emacs channel, while you were intimately familiar with the deal, which is also associated with the emacswiki. If i start to, as you say, “contribute” by editing of the article of removing conversations, that's not gonna go well. Note the fact that the quality of many pages there are in very bad quality as considered as a article. The editing effort will pretty much mean lots of brainless deletions if it is to be meaningful … some of these conversation contains valuable info, but the discussion style makes it hard to extract info or a huge amount of editing effort.

In short, there needs to be some authoritative guideline. Then, the conversation styled dialogs of the wiki would wane. Without such a guideline, and letting tech geekers go freely on what each think is best, is not likely to make emacswiki coherent anytime soon. Large projects requires a leadership. Richard Stallman, is a good example here. (Also note, if emacswiki adopts MediaWiki as its software, it can then use its “discussion” feature, where discussions about usage or preference can be maintained on its own page for each article.)

In summary, there are 2 things i'm saying, and have tried to say to you 2 or 3 years ago, albeit perhaps in a terse manner. (1) One is to adopt WikiMedia, instead being attached to your personal wiki software. (2) It needs a authoritative guideline for emacswiki to grow.

For (2), please don't think it is some Big Brother heavy hand on control. The guidelines need not be harsh, strict, or even enforced. However, it is necessary, that there is such a guideline, and it be required reading for emacswiki editors. (think of Richard Stallman's GNU Manifesto, who actually goes to the trouble of going into legalities with its GPL and FSF corporation.)

Someone wrote:

Alex, have you considered using a third party wiki engine for emacs wiki before?

Alex wrote:

No, never. I use my own software because I know exactly what it does, I have full control over the code, and I feel very comfortable extending it. Switching to something else would mean more work for me. That's why I suggested that anybody interested in it set up their own site, start mirroring Emacs Wiki page content, look at all the background jobs, redirects, URL rewrite rules, text formatting rules, etc. And when they're finished, handing over the domain name will be a trivial thing by comparison. But I'm not willing to do the work for somebody else. They need to do it themselves.

Ok. Thanks for the explanation.