Wiki Engine Review Rhk Criteria Discussion

What I'm Looking for in a Wiki, then Why

The following discussion was refactored from WikiEngineReviewRhkCriteria. Some of the criteria listed there were changed after this was moved. I have changed some of the text here dealing with my reasons for the requirements, but have not changed SunirShah's comments to deal with any of my changes. So, I guess I'm saying read this at your own risk.

SunirShah asked me to motivate my requirements. This is that attempt.

I recognize that some of my reasons (whys) can be satisfied by a variety of capabilities. The requirement to never lose information could be met by password protected editing (maybe) or revision snapshots and rollback capability. I guess I might still like password protection - I can imagine some information that should not be edited except by authorized personnel, like LVLUG meeting announcements or whatever. Maybe not.

Easy to install in Linux (or Windows). Why: I'm a Linux newbie. I'm going to learn Linux (by osmosis or immersion), but I want a Wiki as one of my notekeeping tools during that process - I can't wait to become a Linux expert before I install a wiki. Possible workarounds include continuing to use AskSam on Windows, or installing a wiki on Windows.
Excellent means of finding information, including list of pages and search capability. Why: I intend to put information into the wiki (and let others do the same). We must have good ways of finding it again.
Search should include wild cards, words, phrases, boolean combinations, and within x words, sentences, paragraphs. Why: Part of what I'm looking for is a Linux based replacement for AskSam (and/or ZyIndex?). AskSam has these capabilities. I want to put information into the wiki and be able to find it. If pages can be indexed by a Web search engine, and if I can get a "free" Web search engine, this will address a lot of this point.
Email notification of changes. If I'm using (or "administering") a public wiki, I don't intend to monitor the wiki pages continuously looking to see if new information has arrived. I want to be notified. Ideally, the notification will include a diff or the revised page.
Security. If I put information in, or know that information was put in, I want it to be there when I go look for it. I want it to remain in a recognizable form - I don't think I want to go back to find that it has been completely rewritten and I must read the whole thing again to find what I'm looking for. Thus, if it has been rewritten (hopefully for the better), I may still want to go back to a historical copy that I can recognize. I might even work my way up to the present by working my way through the series of diffs associated with each revision or one diff that takes me from the historical version to the current version. (I'd like to make that choice, individually each time I'm faced with the problem.)

So security translates into some or all of the following:

Password protection on editing
Snapshots of most revisions, and associated rollback and diff capability

Images. Since a picture is worth a thousand words or more, I want some capability to handle images. This might be handled by "inline" images, links to arbitrary URLs, or "attachments".
Tables.
I am willing to forgo embedded HTML based on the potential hazards. If I accept a wiki that allows embedded HTML, I must be able to lock out the capability.
Enhanced WikiNames would be helpful, including numbers and adjacent capital letters. I would like to have WikiNames like "WikiMoinMoinReviewV0.5" and "AFAIK".
Means to format headings beyond the emphasis supplied in the Original Wiki.
InterWiki links. Links of the form WikiSite.WikiPage or WikiSite:WikiPage might make a user's wiki experience more seamless.
Subpages. In essence, I am creating subpages for the WikiCloneReview? by the page naming convention - WikiCloneReviewNotes?, WikiCloneReviewTemplate?, and WikiCloneReviewTemplateAnnotated? are all subpages of WikiCloneReview?. (I guess it doesn't matter whether there is a formal means to create subpages or I do it the way I'm doing it here. On another wiki (the CLUG) I have some pages named like UsingFtpBeginner? and UsingFtpReminder?. More subpages.)
Import / export capabilities: For now, and until I find wikis that I absolutely trust to never lose my information, I maintain backup copies on my PC(unfortunately I'm not 100% consistent in doing this). I create my backups by copying and pasting the pages to and from AskSam. It would be better for me to maintain a local copy of the WikiEngine and have a means to run a script that could copy the pages I wanted to backup. I might identify those pages by a common topic, category, or naming prefix.

Also, the LVLUG (Lehigh Valley Linux Users Group) WikiSite might mirror another site (like the CLUG). If we do, it will be important to have an easy method to import and export pages.

Capable of displaying the text marked up with the WikiOriginalTextFormattingRules:
Translators:

The reason for the previous two capabilities is that I want my wiki pages to be portable. I may move (or copy) individual pages from one WikiSite to another, or I may someday switch from one WikiEngine to another. (I'd like to make as good a choice in WikiEngines as I can now, but I recognize that I may have to (or want to) change that choice in the future. I want the ability to do that as painlessly as possible. (But maybe I am violating the ExtremeProgramming principle of YouArentGoingToNeedIt.))

I don't know if mirroring a WikiSite makes sense. I started this quest with the idea of creating a WikiSite for the LVLUG to replace (or supplement) our discussion forum. I thought mirroring the CLUG site would allow both of us to develop "content" quicker. However, until we run into a bandwidth bottleneck, it makes just as much sense for us to simply use the CLUG WikiSite (with their permission).

Pedantic nit. When referring to this wiki, you can use the terms Wiki, WikiWiki, WikiWikiWeb, PortlandPatternRepository, WardsWiki, or TheOriginalWiki, etc. However, when referring to any particular wiki, use the term "wiki" (lowercase). It's much less confusing, especially if you consider cases like the wiki community and the Wiki community.

Anyway, I shall respond.

Never lose data.

You will automatically fail with a wiki. With the ability to edit other people's text, you can delete, destroy, maim, mutilate, "refactor", move, improve, correct, beautify, etc. existing content. If you respond by maintaining full history, you defeat the purpose of using a wiki: the ability to correct mistakes collaboratively. Instead, you will never forget embarrassing mistakes, unpleasant episodes, vandalism and outright flamewars.

Consider the extreme case if someone posted porn images on a wiki; you could never "forget" the porn and thus, in some way, you are presenting porn on your site. If you did that on a wiki hosted on sunir.org, I could be in big trouble as my site license forbids porn or piracy.

Indeed, read and understand why the WikiNow is absolutely important with an open community.

In a externally constrained organization where complete document tracking is necessary, like say a law firm or a software development house, full history may be essential. This is why we all use version control systems for our source code, for instance. (Well, I wish.)

I understand what you are saying. I believe I can deal with the problems with the right wiki software. I will be looking for a system that stores frequent "revision snapshots" but I will also look for a tool that gives the administrator (at least) the ability to remove pages that must be permanently deleted.

Edit locks

If you do not wish unauthorized people from editing the material, why post it on a wiki? Just use a separate static space for that. Since you are all using Linux, create a group-shared web space for all the administrator.

Making a strong dichotomy between end users and administrators is not a good thing. No one likes god kings (http://usemod.com/cgi-bin/mb.pl?GodKing).

Easy to install in Linux

Most Perl implementations just require that you are running httpd (Apache) and have Perl 5 installed (which is standard on Linux distributions now). Maybe a little mucking around with Apache to turn on CGI scripts, but nothing that you wouldn't need to learn anyway. Things like PHP, ZOPE, JSP, ASP may land you in trouble. Python may come pre-installed, but it's not hard to install anyway.

Running a LUG's website on Windows would be interesting. You could probably anthologize the flamewars for future readers' entertainment.

Yes, it could be interesting. I expect Linux to meet my needs (which sort of implies taking over the desktop), in one to three years. The members of the LVLUG recognize that Linux is not perfect.

Finding information

This is a non-trivial problem. Wikis are extremely bad at information retrieval, often requiring the members to manually link pages together by memory. On the other hand, they are extremely good at letting people build interesting structured hyperdocuments quickly. Most users have a "getting lost" feeling on a wiki because there is no real starting place. Of course, there are the front page, StartingPoints, and a RecentChanges variant on most wikis, but these aren't as useful as the front page of CNN, for instance.

See http://usemod.com/cgi-bin/mb.pl?IndexingScheme for a collection of known (to Meatball) indices.

Also, make Google to index your site.

I'm still confused about what I must do to make Google (or Alta Vista, or ?) index my site. I think I understand that at least some Web search engines will not normally index dynamic web pages. Ahh, but I need to remember what CliffordAdams wrote to me - I think the inference I made was that Google and some other search engines could cache your site (or more likely, I have to cache them at my site) and then Google will index them.

E-mail notification

You won't be able to get the wiki off the ground if you don't monitor it, contribute to it, market it regularly. Wikis don't work until you reach a critical mass of community such that there are always some people contributing at any given time. If you don't have enough eye balls, the PeerReview and most of the SoftSecurity will fail. This is why most open source projects die.

It's a common engineering fallacy to believe if you build it, and it is good, they will come. But as any good marketroid knows, you must advertise, build, encourage or it will fail.

Attract an audience!

I understand, and we (I) might have to do more of that, but my goal is to attract people who need information and who are willing to contribute information.

Security because the content many change

If you are concerned that the content is in constant flux, you really don't want to use a wiki. Wikis facilitate dynamic content. If you want static, archived content, you need a technology that facilitates that.

Consider a WebLog. I recommend the kuro5hin Scoop engine: http://scoop.kuro5hin.org.

I looked quickly and will look again.

Passwords

Passwords are evil. Actually, if you listen to JefRaskin, passwords are stupid. You have an unsecure identifier (your log in name) and a secure identifier (your password). Why do you need both?

Anyway, consider the opposition: on one hand you have a completely open editing structure; on the other, you prevent anyone from getting at it.

Passwords are possibly contingently maybe ok if you want to fishbowl the wiki - i.e. have a small group write the content, while the rest of the world can only read it. For instance, the OrgPatterns site does this. You can also use this for developer's notes that you publish to the web so third party users can see what's going on without fubaring your work.

Tables

Tables are bad. You can't read them in Lynx. Not good for a LUG. Aim for HTML 1.0.

http://usemod.com/cgi-bin/mb.pl?LynxFriendly.

Embedded HTML and more gross style tags

HTML is evil. I really hate the <b> and <i> tags on UseModWiki. In fact, you can see why on http://usemod.com/cgi-bin/mb.pl?EmphasisPattern.

Anyway, there is no good reason to embed HTML. Usually what you want can be easily accomplished with the existing syntax and use of English (English is good!). Consider that books have been published without JigglingBaloney for centuries now, using only a small set of formatting primitives. You can do the same.

Content over form. Information over style.