I just thought of something. What if you could could be a participant once with different options? So therefore if you create blip under "edit only" than blip is only yours to edit. Then if you want to create blip that is open to collaboration you use your incarnation with participant editing). There should be a simple way of switching between incarnations.
There could be a edit only super where the default for participants is edit only. Depending on other supers (public/private) you may or may not be able to add yourself, or be invited under that guise. I think though could be a decent way of dealing with the blip level issue. ________________________________ From: Paul Thomas <[email protected]> To: [email protected] Sent: Fri, 22 April, 2011 13:45:40 Subject: Re: Access Control Yep that make sense. I was thinking "edit own only" after that. It would be nice to explicitly allow editing of your content to others. However blips don't have participant level, merely authors. "edit own only" has been asked for many a time. It is perhaps a bit archaic/antisocial on it own but has it uses. With explicit control of editing that would be really versatile addition. Also probably should be discussion about how AC is actually implemented. We have super users like public and they could have options, also users can have options, and the notion of who has to right to make changes to the AC, with the complication of the originator not necessarily being a participant. ________________________________ From: Arlen Beiler <[email protected]> To: [email protected] Sent: Fri, 22 April, 2011 13:08:01 Subject: Re: Access Control I agree. Read-only should definitely be the third. On Fri, Apr 22, 2011 at 5:43 AM, Thomas Wrobel <[email protected]> wrote: > Read only? Personally I'd love per-wavelet level settings for > individual users but that might be quite complex for now. > > On 22 April 2011 10:47, Paul Thomas <[email protected]> wrote: > > Following Yuri's Poll I noticed that Access control wasn't listed other > then > > public waves. A while ago that issue was discussed. I'll admit I was > probably > > the first to caution. That is becuase I didn't want access control to > become > > inflexible by design, and I was theorising custom access control where in > a > > broader sense you are enabling interaction control. > > > > > > However I think at a more basic level it would be nice to have some of > the more > > common broader use cases. After private, public the next most desirable > access > > control (not suggesting pubic or private are exclusive of these). If > there are a > > handful of common access control options, that are implemented in such a > way > > that won't limit flexibility in the future, I think that will serve to > broaden > > WAIB's appeal. > > > > > > What would be the next desirable ACs? > > >
