which wiki to wiki...

[Greg Rundlett (freephile)]

The OP didn't clarify what access controls were needed.  Broadly
speaking, MediaWiki is not designed to offer content-based access
controls the way that a content management system is designed to do.
It /can/ easily accomodate various types of authentication (and
multi-family wikis) for collaborative authoring in a controlled
environment.


On Sun, Jan 3, 2010 at 6:20 PM, Tom Metro <tmetro-blu-5a1Jt6qxUNc at public.gmane.org> wrote:
> Stephen Adler wrote:
>> Any of you guys have a favourite wiki engine you use?
>
> I've always found the markup syntax inconsistent in MediaWiki,

MediaWiki markup is the de-facto standard.  Efforts on standardization
of wiki markups like Creole and/or converters such as the PEAR
text_wiki classes generally include MW syntax due to it's presence.
Creole was specified by comparing major wiki engines and deciding on
the most common choice for a particular wikitext element. If no
commonality was found, the wikitext of the dominant wiki engine
MediaWiki usually was chosen.
related:
* http://pear.php.net/package/Text_Wiki
* http://www.wikicreole.org/wiki/Engines
* http://www.mediawiki.org/wiki/Extension:XML_Bridge
* http://www.mediawiki.org/wiki/Alternative_parsers
* http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Configuration#HConfiguringWikiSyntaxesanddefaultSyntax
* http://dirkriehle.com/2008/07/19/a-grammar-for-standardized-wiki-markup/

> and the
> functionality to be limited.

MediaWiki software is full of functionality, and extensions.  The
difficulty in creating any standard wiki markup is due to the richness
of the software, syntax and extended syntax.  A lot of people want a
WYSIWYG editor for wikis, however you can't (easily) do in a graphical
editor what you can do (easily and quickly) in wiki markup.  The
template system is one example.  {{This is a template macro|arg1|
arg2}}  What I'm saying is that MW is high on the functionality scale.
 This isn't to say that mediawiki can do anything and everything -- it
can't.  It is narrowly focused in it's purpose (collaborative
authoring with ad-hoc structure).  Using mediawiki for documentation
and knowledge-sharing is well-established.
related:
http://www.mediawiki.org/wiki/Extension:Contents

> People seem to install it almost by
> default, which is unfortunate.

If you need a collaborative authoring environment, then it's very
fortunate that you might install MediaWiki :-)

On the other hand, if you need "a wiki" because somebody wants an
easy-to-edit website where most pages will have an individual author
with lots of access control and separation, groups, project pages,
levels of access etc. then what they asked for was a wiki, but what
they need is a CMS.

>
> Wikispaces is great for situations where outsourcing your wiki to a
> hosting provider is appropriate.

Agreed

>
> But ultimately I'll add another vote for Twiki. I haven't set one up in
> a few years, but you can make it do just about anything if you're
> willing to put the time in. And that doesn't necessarily mean modifying
> the core Perl code. It's extensively configurable and programmable from
> the web UI. Plus there's a big library of plugins.

You don't want to modify any core code in project unless you're
actively trying to commit that code upstream.

>
> I do, however, read that there has been con controversy around the
> project, and a fork spun off, http://foswiki.org/. A few months back the
> people behind the fork obtained a backup of the twiki.org user records,
> sent out a mass mailing promoting the fork, followed a few days later
> with an email from the Twiki founder refuting the claims in the prior
> email. Whatever...but the point is you'll probably want to assess both
> projects and see which is on the track you want to follow.
>

Forks happen, and sometimes it's because you can't get your code
committed upstream.  But, it's more often a political divide and one
that ultimately weakens/dilutes the software/community for the user.
If I were starting a project and selecting software to use in that
initiative, I'd probably steer clear of software that is forking
unless I understood the situation fairly well.


Greg Rundlett

nbpt 978-225-8302
m. 978-764-4424
-skype/aim/irc/twitter freephile
http://profiles.aim.com/freephile