MediaWiki instead of Trac Wiki?

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

MediaWiki instead of Trac Wiki?

Derek Atkins
Should we install MediaWiki and use that instead of the Trac Wiki on
the gnucash server?  I'll note that MediaWiki will require installing
mysql -- although I can firewall it all off..  I'm just wondering
what the masses at large think?  Opinions?

-derek
--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki instead of Trac Wiki?

Tim Wunder (Lists)
On Monday 28 November 2005 11:53 am, someone claiming to be Derek Atkins
wrote:
> Should we install MediaWiki and use that instead of the Trac Wiki on
> the gnucash server?  I'll note that MediaWiki will require installing
> mysql -- although I can firewall it all off..  I'm just wondering
> what the masses at large think?  Opinions?
>

Reasons to use MediaWiki:
- Migration from gnomesupport.org would be an easy file copy, or at worst, a
copy/paste edit
- MediaWiki has a functioning TOC
- MediaWiki allows users to edit specific sections of a page, like in the
Gnucash FAQ on gnomesupport.org
- MediaWiki has more formatting options available to it

Tim

--
Fedora Core release 4 (Stentz), Linux 2.6.14-1.1637_FC4
KDE: 3.4.3-1.1.fc4.kde, xorg-x11-6.8.2-37.FC4.49.2
 12:40:02 up 8 days,  4:58,  3 users,  load average: 0.13, 0.04, 0.01
MP3/OGG archive Total playlength : 7 days, 10 hours, 31 mins 30 seconds
"It's what you learn after you know it all that counts" John Wooden

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki instead of Trac Wiki?

Paolo Benvenuto
El lun, 28-11-2005 a las 12:50 -0500, Tim Wunder escribió:

> On Monday 28 November 2005 11:53 am, someone claiming to be Derek Atkins
> wrote:
> > Should we install MediaWiki and use that instead of the Trac Wiki on
> > the gnucash server?  I'll note that MediaWiki will require installing
> > mysql -- although I can firewall it all off..  I'm just wondering
> > what the masses at large think?  Opinions?
> >
>
> Reasons to use MediaWiki:
> - Migration from gnomesupport.org would be an easy file copy, or at worst, a
> copy/paste edit
> - MediaWiki has a functioning TOC
> - MediaWiki allows users to edit specific sections of a page, like in the
> Gnucash FAQ on gnomesupport.org
> - MediaWiki has more formatting options available to it

- MediaWiki permits to have article titles with spaces, allowing more
readable pages

--
Buon Cammino!

don Paolo Benvenuto

Vuoi sapere di più su quello che succede qui?
leggi il mio diario a http://www.chiesamissionaria.it/diario

Visita l'enciclopedia libera, dove puoi contribuire anche tu:
http://it.wikipedia.org/


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki instead of Trac Wiki?

Derek Atkins
In reply to this post by Derek Atkins
Didier Vidal <[hidden email]> writes:

> I'm a MediaWiki fan. I would welcome such a move if it doesn't slow down
> the server performances.

[root@cvs svn]# uptime
 18:37:33  up 127 days,  7:44,  1 user,  load average: 0.00, 0.00, 0.00
[root@cvs svn]# free
             total       used       free     shared    buffers     cached
Mem:        513096     502640      10456          0      73124     263716
-/+ buffers/cache:     165800     347296
Swap:      1046192     265632     780560

So... I suspect it could use a little more RAM, but in general
the machine isn't loaded.

-derek

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki instead of Trac Wiki?

Christian Stimming
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:

1. http://www.gnucash.org/
2. the gnucash-docs svn module, online copy at
http://www.gnucash.org/docs/v1.8/C/gnucash-help/help.html
3. http://gnomesupport.org/wiki/index.php/GnuCash

The places #1 and #2 by definition have strictly limited access and slow
update-cycles and there are good reasons for that (although major parts
of #1 are outdated and need to be overhauled or moved to the wiki). The
place #3 on the other hand is truly a wiki in the wiki sense -- everyone
can create an account on gnomesupport.org and therefore start to
contribute. The spam issue exists there but it is manageable [1]. How
would the Trac wiki fit into this picture? I don't think we should add
this as a fourth place for gnucash. Also I do think we should have a
wiki that doesn't require manual account creation by the maintainer, but
should instead have a quite low entry barrier for contributions from
new/lurking/fringe/whatever contributors.

So the question now is: Which server do we want to use for a wiki in the
long-term? Either continue with gnomesupport.org or fully switch to our
own wiki server? Actually it would be good to hear from the
gnomesupport.org admin whether he (stro) really wants to continue
gnomesupport.org (email sent; will post reply to list). Gnucash makes up
approx. 80% of the content there [2], although quite recently one user
called "Macv" copied a lot of general content from wikipedia [3], but
apart from that there is virtually zero content there.

I'm quite agnostic to this actual question - either one of the wiki
servers would be fine IMHO. I do think that we should decide on one of
them though, and I do think that our wiki should be quite open to
contributions, similar to the current gnomesupport policy.

Christian


[1] gnomesupport.org has a spammer visiting maybe every other week. You
cannot contribute anonymously but you have to create an account. If any
account causes spam, the admins have that super-fast rollback function
on a per-account basis, so it's only a matter of one click to revert
spam of one account. Currently I'm the only active admin and it's
sufficient that I spend 1 minute every other day to check for and fix
that spam. So that's a bearable effort.

[2] http://gnomesupport.org/wiki/index.php/Special:Popularpages
[3] http://gnomesupport.org/wiki/index.php/Special:Newpages

Derek Atkins schrieb:
> Didier Vidal <[hidden email]> writes:
>
>
>>I'm a MediaWiki fan. I would welcome such a move if it doesn't slow down
>>the server performances.
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki instead of Trac Wiki?

Josh Sled
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. :/

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


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.

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.

...jsled
--
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: 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.
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki instead of Trac Wiki?

Derek Atkins
Quoting Chris Shoemaker <[hidden email]>:

> 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

I would want this somewhere betweeen #2 and #3.

> 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.)

There's no plan to deinstall trac.  The only real question is whether
we should turn "off" the trac wiki.  I'll note that the trac svn browser
is missing the annotate feature that exists in viewcvs.

-derek

PS: I've proposed to Linas that www.gnucash.org content get pulled from
svn.  I'm waiting for a response.

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki instead of Trac Wiki?

Josh Sled
In reply to this post by Chris Shoemaker
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.

> *) 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.

Agreed.

...jsled
--
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki instead of Trac Wiki?

Chris Shoemaker
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.
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki instead of Trac Wiki?

Chris Shoemaker
In reply to this post by Josh Sled
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.

Now a question unrelated to my main point...

Assuming no account is needed to *read* content, what possible
incentive is there to create an account that has no edit privilege?
It lets me read under my own username?  Is it a dirty trick?

Unless I misunderstand, this just won't work.

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki instead of Trac Wiki?

Derek Atkins
Quoting Chris Shoemaker <[hidden email]>:

> 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.
>
> Now a question unrelated to my main point...
>
> Assuming no account is needed to *read* content, what possible
> incentive is there to create an account that has no edit privilege?
> It lets me read under my own username?  Is it a dirty trick?

The incentive is that you need an account in order to edit content.
It's just a question of the delay between creating the account and
being able to edit content.

> Unless I misunderstand, this just won't work.

Why do you say that?  It just wont work unless the delay is zero?
Why do you believe that to be true?  Isn't that as much an assumption
as the level of wiki-spam that you're arguing so vociferously about?

> -chris

-derek

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki instead of Trac Wiki?

Josh Sled
In reply to this post by Chris Shoemaker
On Wed, 2005-11-30 at 14:12 -0500, Chris Shoemaker wrote:

> 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.
>
> Now a question unrelated to my main point...
>
> Assuming no account is needed to *read* content, what possible
> incentive is there to create an account that has no edit privilege?
> It lets me read under my own username?  Is it a dirty trick?
>
> Unless I misunderstand, this just won't work.

This would effectively be using mediawiki's account creation as the
"webform for requesting write-access": one creates an account, sysops
are signaled, the account gets the 'edit' perm added, then one can edit
pages.


WRT the abuse-level threshold tuning... we need to choose a specific
mechanism, and I'm not going to spend time measuring the allowed and
prevented abuse fractional rates or whatever.  Let's do one of these
two:

- account creation with moderated editing approval, see how it goes and
maybe relax it later to account-creation with unmoderated editing
approval.  

- start more permissive, allowing anons to create accounts with edit
perms by default, and regress iff spammers take hold.

...jsled
--
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki instead of Trac Wiki?

Chris Shoemaker
In reply to this post by Derek Atkins
On Wed, Nov 30, 2005 at 02:38:46PM -0500, Derek Atkins wrote:
> >Now a question unrelated to my main point...
> >
> >Assuming no account is needed to *read* content, what possible
> >incentive is there to create an account that has no edit privilege?
> >It lets me read under my own username?  Is it a dirty trick?
>
> The incentive is that you need an account in order to edit content.
> It's just a question of the delay between creating the account and
> being able to edit content.

Ah, so a user knows before he signs up for the account that he won't
be able to do anything with the new account that he couldn't do with
no account... unless and until someone flips the bit on his account?
I predict that user participation will be *very* strongly correlated
with their expectation that they will certainly and promptly receive
write access.

> >Unless I misunderstand, this just won't work.
>
> Why do you say that?  It just wont work unless the delay is zero?

I thought Josh was describing something effectively different from
manual account creation.  I think I misunderstood.

> Why do you believe that to be true?  Isn't that as much an assumption
> as the level of wiki-spam that you're arguing so vociferously about?

Well, I wasn't suggesting that such a scheme would result in any
particular amount of wiki-spam, only that a very high expectation of
being able to edit content is the only motivation I can think of for
requesting an account.

As for the effect that time-delaying the write-bit would have on
wiki-spam, I have no idea what to expect.  I've never heard of that
technique.  Is it intended to deter human vandals or wiki spam-bots?

BTW, I'm much more confident of my (and others) ability to predict the
effect of restrictions on benevolent users than I am of my (and
others) ability to predict the effect of those same restrictions on
the level of wiki-spam.  Something about me being a friendly human
probably...

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki instead of Trac Wiki?

Chris Shoemaker
In reply to this post by Josh Sled
On Wed, Nov 30, 2005 at 02:46:17PM -0500, Josh Sled wrote:

> > Assuming no account is needed to *read* content, what possible
> > incentive is there to create an account that has no edit privilege?
> > It lets me read under my own username?  Is it a dirty trick?
> >
> > Unless I misunderstand, this just won't work.
>
> This would effectively be using mediawiki's account creation as the
> "webform for requesting write-access": one creates an account, sysops
> are signaled, the account gets the 'edit' perm added, then one can edit
> pages.

I see now.

> WRT the abuse-level threshold tuning... we need to choose a specific
> mechanism, and I'm not going to spend time measuring the allowed and
> prevented abuse fractional rates or whatever.  Let's do one of these
> two:
>
> - account creation with moderated editing approval, see how it goes and
> maybe relax it later to account-creation with unmoderated editing
> approval.  
>
> - start more permissive, allowing anons to create accounts with edit
> perms by default, and regress iff spammers take hold.
>

:) Yes.  That's almost exactly what was trying to suggest. :) The
important parts being "see how it goes" and "iff spammers".  I didn't
mean to imply that measurements and threshold *had* to be precise.
"Hey that's too much spam!" is a valid measurement and comparison to
the threshold.  (I would just change "maybe relax" to "certainly relax
if there's not too much spam".)

I've seen more than one wikidom rot because it reacted against
wiki-spam by restricting it away, along with all useful collaboration.
:(  We can do better.

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki instead of Trac Wiki?

Chris Shoemaker
In reply to this post by Josh Sled
On Wed, Nov 30, 2005 at 02:46:17PM -0500, Josh Sled wrote:

> WRT the abuse-level threshold tuning... we need to choose a specific
> mechanism, and I'm not going to spend time measuring the allowed and
> prevented abuse fractional rates or whatever.  Let's do one of these
> two:
>
> - account creation with moderated editing approval, see how it goes and
> maybe relax it later to account-creation with unmoderated editing
> approval.  
>
> - start more permissive, allowing anons to create accounts with edit
> perms by default, and regress iff spammers take hold.
>

Oh, regarding choosing between these two: If the second case
corresponds to the restrictions at gnomesupport.org, then we already
have Christian's data on how much wiki-spam that causes.  We can
choose between them based on the acceptability (or unacceptability) of
that rate.  I think whoever is most likely to spend the most time
moderating should make that judgement, and I'm guessing that would be
Christian since he's already in the habit of moderating
gnomesupport.org.

Also, the focus tends toward the setting of the restriction-level
since that's viewed as a free-variable, but I want to re-emphasize
that lowering the cost of the corrective action is *really* important.
Any wiki should be read-only until those mechanisms are well-greased.

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki instead of Trac Wiki?

Josh Sled
On Wed, 2005-11-30 at 15:59 -0500, Chris Shoemaker wrote:
> Also, the focus tends toward the setting of the restriction-level
> since that's viewed as a free-variable, but I want to re-emphasize
> that lowering the cost of the corrective action is *really* important.
> Any wiki should be read-only until those mechanisms are well-greased.

Mediawiki has a couple of quick-revert features that're generally
regarded as very good ... they were forged in the fires of Wikipedia,
after all.  http://meta.wikimedia.org/wiki/Help:Reverting

...jsled
--
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki instead of Trac Wiki?

Chris Shoemaker
On Wed, Nov 30, 2005 at 04:17:22PM -0500, Josh Sled wrote:
> On Wed, 2005-11-30 at 15:59 -0500, Chris Shoemaker wrote:
> > Also, the focus tends toward the setting of the restriction-level
> > since that's viewed as a free-variable, but I want to re-emphasize
> > that lowering the cost of the corrective action is *really* important.
> > Any wiki should be read-only until those mechanisms are well-greased.
>
> Mediawiki has a couple of quick-revert features that're generally
> regarded as very good ... they were forged in the fires of Wikipedia,
> after all.  http://meta.wikimedia.org/wiki/Help:Reverting

Yes, they are very good.  However, I'm surprised there's no multi-page
admin roll-back.  I mean, if the admin wants to roll-back a single
page why not (optionally) roll-back *all* pages last edited by that
user and why not (optionally) ban, or at least temporarily restrict
said user, all in one operation?  

I realize these features are over-kill for GnuCash, but for Wikipedia?
Perhaps I over-estimate the volume of wiki-spam.

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki instead of Trac Wiki?

Karl Hegbloom
In reply to this post by Josh Sled
On Tue, 2005-11-29 at 09:55 -0500, Josh Sled wrote:
> 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.

If you search on the Firefox extension download site, you'll find two
really cool tools for working with Wiki pages.  One is the Wikipedia
tool bar, and the other is 'save text area' which lets you save a text
edit area to a file, and load it's contents from a file.

I'm thinking of a hack where a daemon or an emacs sub processes watches
for a file to appear, and when it does, calls on 'gnuclient' to open it
for editting.  When the file is saved back, somehow the browser should
notice and load it again.  :-)  I don't know how to do the second part.

--
Karl Hegbloom <[hidden email]>

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki instead of Trac Wiki?

Chris Shoemaker
In reply to this post by Chris Shoemaker
On Wed, Nov 30, 2005 at 11:48:49PM +0100, Didier Vidal wrote:

> Le mer 30/11/2005 à 22:43, Chris Shoemaker a écrit :
> > Yes, they are very good.  However, I'm surprised there's no multi-page
> > admin roll-back.  I mean, if the admin wants to roll-back a single
> > page why not (optionally) roll-back *all* pages last edited by that
> > user and why not (optionally) ban, or at least temporarily restrict
> > said user, all in one operation?  
> >
> > I realize these features are over-kill for GnuCash, but for Wikipedia?
> > Perhaps I over-estimate the volume of wiki-spam.
> Or underestimate the volume of contributors. Mass moderation plays a
> role.

Good point.  The roll-back is a feature reserved for "admins" and I'm
presuming these are a very small group, but I don't actually know how
many there are.

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
12