MediaWiki instead of Trac Wiki?
Chris Shoemaker
c.shoemaker at cox.net
Wed Nov 30 14:07:11 EST 2005
On Wed, Nov 30, 2005 at 12:15:21PM -0500, Josh Sled wrote:
> On Wed, 2005-11-30 at 11:59 -0500, Chris Shoemaker wrote:
> > 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
>
> We've been talking (in IRC) about somewhere between (2) and (3) ...
> specifically: anyone can create an account via the wiki, but it comes
> w/o edit privs; sysops will then add the edit perm to accounts
> individually.
Just to clarify the main point I was making...
I'm not advocating a particular restriction setting. I'm speaking
against the tendency to set the restriction level based on intuition,
desire or expectations. Instead, decide on the *desired* abuse-rate,
and choose the restriction level empirically measured to achieve that
abuse-rate. This is especially problematic when misguided wiki-admins
intuitively seek the restriction-level intended to achieve a zero
abuse-rate.*
Put bluntly, I don't trust my intuition to accurately map
restriction-levels into abuse-rates. Nor anyone else's intuition
unless they have considerable experience measuring the abuse-rate for
GnuCash's content-type. I trust Christian's report of abuse-rate
given the particular restriction-level that gnomesupport.org uses, but
everything else is speculation.
I'm advocating:
(after addressing the revert mechanisms)
- choose threshold abuse-rate.
- if Christian's reported abuse rate is too high, set
restriction-level higher (might as well start at (2)), lower
restrictions until abuse rate meets criteria
- if Christian's reported abuse rate is too low, set restrictions
where they were for gnomesupport, measure abuse, and if still too low,
lower restrictions as above.
My claim is that this is the method that will most effectively achieve
the most vibrant, helpful and *accurate* wiki.
Obviously, there is some on-going measurement and feedback required,
since not all variables are constant. E.g. wiki-spammers get smarter;
as # mods increases, any abuse-rate that is formulated "per mod" will
decrease.
I really can't tell whether you (or the IRC conversants) agree with
the claim, disagree with the claim, didn't understand the claim, or
just don't care.
-chris
*) Believe it or not, this is often actually worse than having the
content not in the wiki at all, but rather in some other CMS or doc
format. This is because using the wiki format still incurs an
usability inefficiency cost that must be compensated for by
collaboration efficiency to make it worthwhile. However, better
wiki-implementations are gradually reducing this effect.
More information about the gnucash-devel
mailing list