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

Eric Johnson eric at tibco.com
Mon Nov 29 17:08:44 EST 2010


Hi George,

On 11/29/10 1:54 PM, George Georgalis wrote:
> 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?

That's simply documented at the top of the page.  If we were feeling 
particularly clever, I'd push to create a macro that would add some sort 
of background styling on the page so that it was obvious. Haven't done 
that, yet.

-Eric

> 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