On 26 November 2010 12:38, 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 > > I think this is rather too complex for wavelet permissions. In particular, I think it's counter-productive that only Managers and above can add participants. Sharing a wavelet is fundamentally valuable so in a linear hierachy like this I think it should appear around editor or contributor. This implies the Manager role is redundant.
Perhaps some use cases describing some typical collaboration scenarios would help settle this list. It's also not clear that a linear hierachy is the right model, as opposed to orthogonal capabilities, though it does have the advantage of being simple. > > > 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]<wave-protocol%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > -- 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.
