incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean Hollis Weber <jeanwe...@gmail.com>
Subject Re: Access to wiki
Date Fri, 05 Aug 2011 01:43:30 GMT
On Thu, 2011-08-04 at 15:01 +0100, Simon Phipps wrote:
> On 4 Aug 2011, at 14:56, Rob Weir wrote:
> 
> > On Thu, Aug 4, 2011 at 7:29 AM, TerryE <ooo@ellisons.org.uk> wrote:
> >> On 04/08/11 11:31, Jean Weber wrote:
> >>> 
> >>> <snip>
> >>>>> 
> >>>>> 2) Alternatively, or in addition, the first X edits/ contributions/
> >>>>> whatever are moderated by a group of people, any one of whom can
approve
> >>>>> or reject the items. After X acceptable contributions, the person
is
> >>>>> then allowed to edit the wiki without further supervision -- until
or
> >>>>> unless they start posting inappropriate material such as spam. Again,
> >>>>> very few spammers will take the trouble to post some useful info
before
> >>>>> going into spam mode.
> >>>>> 
> >>>>> These methods deal with the vast majority, if not all, of the concerns
I
> >>>>> have seen Rob expressing about systems with no control at all, but
at
> >>>>> the same time they do not require more time or commitment on the
> >>>>> contributors' part to be authorised to participate.
> >>>>> 
> >>>>> AFAIK, most wikis&   similar sites provide some way to limit
the editing
> >>>>> of specific pages to a smaller group of people (admins or whatever).
> >>>>> 
> >>>> <snip>
> >>> 
> >>> You probably know more about this than I do, but my understanding is that
> >>> the current OOo wiki has an extension installed that does what I was
> >>> suggesting in option 2, but the extension has not been implemented.  See:
> >>> http://www.mediawiki.org/wiki/Extension:FlaggedRevs and specifically:
> >>> 
> >>> http://www.mediawiki.org/wiki/Extension:FlaggedRevs#Automatic_user_promotion
> >>> 
> >> Jean
> >> 
> >> Yes, you are correct.  This is extension can do this and more, but with a
> >> grey issue like this I feel that a DL based dialogue isn't the best way to
> >> work out what to do here.  Better we work up a position paper/page within
> >> the OOOUSERS cwiki laying down the options, their pros and cons and then
> >> agree a consensus or vote either on the paper itself.  Use the DL to note
> >> the consensus and get wider feedback.
> >> 
> >> What concerns me is the moderation load involved with such an active
> >> intervention of review-before-publish.  Perhaps others with moderator
> >> experience might care to comment?
> >> 
> > 
> > The general approach at Apache is to grant trust once merit has been
> > shown.  So we should be liberal in granting additional rights to
> > contributors who make consistent, high quality contributions.  If
> > moderation is a bottleneck then it shows that we're not distributing
> > power efficiently.
> 
> Given Jean's next paragraph, how would a potential contributor be able to establish that
reputation? 
> 
> > 
> >> My worry is that review-before-publish also ignores the reality of how
> >> people edit wikis.  In general they don't prepare and proof draft offline
> >> then paste their best and final into the article.  Most do it section by
> >> section or end up correcting / rewording when they see the final version, so
> >> one logical edit can comprise half a dozen posts.  I am not sure how this
> >> would work if you've got to wait for approval before the next edit.
> >> 
> >> We also still need the quality checks: does the email exist, who is she/he,
> >> etc. and I am not sure how we could include these in an automaic bump.

Just for the record, the "next paragraph" in the quoted material above
was not mine, but Terry's.

--Jean


> >> 
> >> Terry
> >> 
> >>> --Jean
> >>> 
> >>> 
> >> 
> >> 
> 




Mime
View raw message