MediaWiki instead of Trac Wiki?

[Chris Shoemaker]

On Tue, Nov 29, 2005 at 09:55:38AM -0500, Josh Sled wrote:
> On Tue, 2005-11-29 at 11:22 +0100, Christian Stimming wrote:
> > Actually I'm still unsure whether we really should start maintaining a 
> > non-trivial wiki on svn.gnucash.org (I hope this question doesn't sound 
> > blasphemic by now).
> > 
> > Currently we have online documentation about gnucash at the following 
> > places, which are all maintained differently:
> 
> Yeah, it's annoying.
> 
> - We should be able to update www.gnucash.org more readily; the current
> situation is fairly silly.  If not machine/update access, it'd be nice
> if the sources were in svn so they could be updated, patched, &c.  It'd
> also be nice if, maybe, the site was regularly (auto-)updated from svn.
> 
> - I feel like we're leeching off gnomesupport.org; we could stand to
> have a gnucash-specific wiki on wiki.gnucash.org.
> 
>   - We should require moderated accounts for editing; while it's not the
> wiki way, spammers have more evil than we have free time. :/

There are two ways to fight wiki spam: 1) Make it harder for spammers
to spam (and regular people to contribute).  2) Make it easier to
revert unwanted content.

These two ways need to be balanced.  My philosophy/strategy for
balancing them is exactly the same as for F/OSS development (after
all, wiki is just OS document prep.)  That is:
   a) Use available technical means to push 2) as far as reasonably possible.
   b) Reduce the use of 1) to the point where abuse-rate is
measurable, tolerable and non-zero.  (Yes, a zero abuse-rate is
*undesirable*.)

In the context of a gnucash wiki, I would apply these principles thusly:
   a) One-click auto-revert and account/ip ban available to moderators; 
      web-form for readers to alert mods to presence of wiki-spam.
      recently-modified lists; account-age visibility; etc.
   b) Spectrum goes:
      1) no user edits; only moderators edit/add new mods
      2) same as 1) w/ webform for requesting write-access. (manual approval)
      3) same as 2) but with CAPTCHA, email callback and automatic approval 
      4) same as 3) but without CAPTCHA
      5) same as 4) but with no email verification
      6) anonymous edits

      Choose desired abuse-rate-threshold (e.g. abuse affecting >=.5%
of content is reverted in <= 12 hours at least 50% of the time and
revert/ban-rate is < 1 revert per moderater per day).  Reduce
restrictions to lowest point below abuse-rate-threshold.
Incidentally, I would predict (estimate?) that for a reasonably chosen
abuse threshold (I'm not claiming my off-the-cuff example is
reasonable) the restriction threshold point will be either 4) or 3),
and probably 4).

> - I could imagine some wiki-like system for maintaining or commenting on
> the gnucash docs, but that's a ways down the road.

Perhaps it's far away because of level-of-effort but it's not
technically very far away.

> It sounds like the Trac-provided wiki isn't really working out, and
> MediaWiki is (relateively) easy to setup, full-featured and well-known.
> I say we try it out, and dereference gnomesupport.org.

Ok, but the Trac-provided changeset viewer is valuable, so let's keep
it.  It's a bit ugly IMO, but the info is there.  (I know you only
mentioned the wiki, but I'm just reminding (mostly myself) that 
Trac > wiki.)

> We should also move much of the www.gnucash.org content into the wiki,
> eventually combined with reducing the footprint of www.gnucash.org to
> really-static information and/or merging the two entirely.

There does come a point when obsolete info (misinformation) is worse
than no info at all.  IMO, www.gnucash.org has been approaching that
point for some time*, and will (absent intervention) certainly pass
that point concurrent with the G2 release.  However, I really don't
know how much that is attributable to lack-of-access and how much to
lack-of-effort.  I suppose access is necessary prerequisite for
effort.

-chris

*) Actually, for a (potential) developer it is already worse than
nothing since google will lead to correct dev info more readily than
www.gnucash.org.  For an average user, the problem is not so acute.