I'm certainly in favour of as flexible as possible edit system. A creator of a blip being able to set who else can edit it, or to make it totaly read-only would be incredibly usefull for the use-case I'm working on. Ditto for the whole wave. Read-only, adding, full edit etc.
My only issue would be just a minor one over naming. Contributor all be a bit too technical-sounding for a casual user. (and while clients are free to abstract/rename as they please, it would be nice to keep a uniform naming to some extent). So Id suggest trying to keep things friendly/easy as possible for regular users to understand. In many ways it should be as simple as sharing google- documents and setting editing permissions on those. On Dec 1, 10:42 pm, STenyaK <[email protected]> wrote: > I'm not actively involved in wiab development, but here's some thoughts: > > I think we can all agree that Wave is suitable for replacing many > communications forms: email, mailing lists, forums, doodles, wikis, > google docs... > Each one of these existing communications forms exist and is widely > used, because it suits certain usage patterns. > > If[*] wave's "purpose" is to be able to replace all of these other > forms, the groups/permissions system must be a superset of all the > options available in current communication forms. Otherwise, we'll > find use cases in which Wave is not suitable for some reason or > another, therefore giving people valid excuses not to migrate to Wave, > and keep the current mess of communications we have nowadays. > > If we apply this idea to groups/permissions, then we should be able to > make any blip non-editable by anyone (email style), or editable only > by owner and "admin" group (forums), or rejectable by "admin" group > before it's published (moderated mailing list), etc. > Note that the above is just a very very simple example so that you get > an idea of what I mean. > > When trying to come up with that superset of features, it'll probably > be possible to refactor them into a much smaller set of > rules/features, that combined together in certain ways can replicate > the behaviour of existing communication forms. In my opinion, we > should strive for that. > > [*] That's what I'd like wave to become, but other people may > disagree. I'm not sure if there's even an official definition of what > wave tries to be? > > > > > > > > > > On Fri, Nov 26, 2010 at 18: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 > > > 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. > > -- > Saludos, > Bruno González > > _______________________________________________ > Jabber: stenyak AT gmail.comhttp://www.stenyak.com -- 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.
