Probably the single most requested feature from the people I work with
was the ability for a user to lock a blip so no one else could edit it
until they unlocked it (and, incidentally, that new blips were created
in a locked state).

I know that breaks the whole collaborate wave thing a bit, but a lot
of people I know were _really_ uncomfortable with having their
messages edited by other people (it only takes one prankster. :P), and
it made embedded waves a real mess. Having sections of a wave that
were collaborative, and sections that weren't was something that
people asked me about a lot.

I think it'd be relatively simple to modify the document model to
support a locked field for blips; federating that might be difficult,
but it'd work reasonably well for groups too.

I definitely think that locking at a blip level rather than a wavelet
level is needed.

~
Doug.

On Nov 27, 1:38 am, Tad Glines <[email protected]> wrote:
> I'm working on adding group support to WiaB and also looking at the issue of
> wavelet permissions.
>
> As a starting point I want to propose some group and wavelet roles and
> solicit feedback.
>
> For groups the roles I'm proposing are:
>
>    - Reader
>       - May read waves on which the group is a participant.
>    - Contributor
>       - Includes Reader capabilities
>       - May submit deltas to wavelets for which group is a participant. The
>       delta author must be the submitter.
>    - Manager
>       - Includes Contributor capabilities
>       - May add/remove members to/from the group and modify the role of
>       existing members, but only if:
>          - The member is self
>          - The member is NOT a manager
>          - The member is NOT an owner
>       - Owner
>       - Includes Manager capabilities
>       - May add/remove members to/from the group and modify the role of
>       existing members, but only if:
>          - The member is self
>          - The member is NOT an owner.
>
> For wavelets the roles I'm proposing are:
>
>    - Reader
>       - May read wavelet content
>    - Contributor
>       - Includes Reader capabilities
>       - May add new wavelet content. In the context of a conversation
>       wavelet, this implies adding new blips.
>       - May edit own content. In the context of a conversation this implies
>       editing or deleting own blips.
>    - Editor
>       - Includes Contributor capabilities
>       - May add/edit/delete any content.
>    - Manager
>       - Includes Editor capabilities
>       - May add/remove participants and modify the roles of any exiting
>       participant if:
>          - Participant is self
>          - Participant is NOT a Manager
>          - Participant is NOT an Owner
>       - Owner
>       - Includes Manager capabilities
>       - May add/remove participants and modify the roles of any exiting
>       participant if:
>          - Participant is self
>          - Participant is NOT an Owner
>
> For both groups and wavelets the creator would be granted the owner role.
>
> -Tad

-- 
You received this message because you are subscribed to the Google Groups "Wave 
Protocol" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/wave-protocol?hl=en.

Reply via email to