[Moin-user] feature request open wiki in controlled world

George Georgalis george at galis.org
Mon Nov 29 16:54:28 EST 2010


Hello Eric,

On Mon 29 Nov 2010 at 09:59:02 AM -0800, Eric Johnson wrote:
>My take is that you can solve the problem with the tools you have,
>rather than inventing new ones.

Yes, this is generally the best solution.

But your approach has a problem when a casual user follows a link
to the wiki. How will they know if it is an ACL restricted release
page or some random wild page someone posted. How will the casual
user even know there is a difference?

I raised the same question on a NetBSD list, here is an interesting
answer. http://mail-index.netbsd.org/netbsd-users/2010/11/27/msg007187.html

It turns out, they are customizing their wiki so the top half of
each page requires a developer login while the bottom half can be
edited by anyone.

-George


>For example, one approach we're taking is to have an "official" copy
>of a page (tightly restricted via MoinMoin ACLs), and a freely
>editable copy.  It is then up to the "owners" of the page to watch
>the freely editable copy, and move those changes over according to
>whatever rules they establish for themselves.
>
>If you think about what you've described below, it amounts to almost
>the same steps - a less privileged member has to click a link to get
>to the page that allows "wild" edits, and only members of the the
>privileged group can copy materials back to the "official copy".
>
>Even better, though, for people who are just interested in the
>"official" copy, they can see the changes over time that were
>explicitly accepted by the privileged group, without the noise of
>piecemeal edits that may or may not be allowed.  This approach also
>allows flexible rules about when materials get copied over (official
>sign-off at one extreme, quick daily reviews at another).
>
>-Eric.
>
>On 11/26/10 12:29 PM, George Georgalis wrote:
>>Everyone here knows the benefits of wiki. When a "trust but
>>verify" approach is applied, the return from allowing open edits
>>far outweighs the risk of mis-information.
>>
>>But what about in a controlled orginization? Where there is desire
>>to use a wiki but policy or procedures prevent it.
>>
>>Perhaps a simple module can go a long way to address the
>>situation.  The hypothetical module gives users the option to
>>view the revisions last edited by AuthorizedGroup or the "wild
>>revision" (edits by users not in that group). Pages would default
>>to the authorized revision if that is newer than the wild type but
>>there would be an indication on the authorized page if a newer
>>wild revision where available.
>>
>>The biggest problem I see with this is broken links or inappropriate
>>references due to mis-qualified page links. But the more I imagine
>>the implementation the less I think this would be an actual problem?
>>
>>Thoughts? Would this be easy or difficult to implement?  I'm happy
>>to post this in the wiki feature request, if people think it's a
>>worthwhile feature.
>>
>>-George
>>
>>------------------------------------------------------------------------------
>>Increase Visibility of Your 3D Game App&  Earn a Chance To Win $500!
>>Tap into the largest installed PC base&  get more eyes on your game by
>>optimizing for Intel(R) Graphics Technology. Get started today with the
>>Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
>>http://p.sf.net/sfu/intelisp-dev2dev
>>_______________________________________________
>>Moin-user mailing list
>>Moin-user at lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/moin-user
>




More information about the Moin-user mailing list