On 1 December 2010 09:42, 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? >
I'm going to have to disagree here. Trying to be all things to all people was one of the fundamental weaknesses in Google Wave. It led to a complex product that was kinda good at lots of things, but not fantastic at any. Over time we iterated towards document/wiki style collaboration as one use case at which Wave particularly excelled, but it was still a bit confusing. I don't think having a "purpose" of replacing all those systems is a good idea. It will lead to huge amounts of both product and technical complexity. I would much prefer WIAB focussed on a smaller target, at least to start. The one I would suggest it's closest to already is small group collaboration. But that's just my opinion. Perhaps this community should work towards agreeing on a target ideal. > > > 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]<wave-protocol%[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.com > http://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]<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.
