Here is the second proposal posted by the newcomer Michael van Schaik and worth of discussion here on the discussion list:
- Design & implement group-structure for collaborations / interactions; In order to collaborate, users should be able to form groups that can work together on trails & shifts. Shifts could then be owned by users and groups, and have permissions set for this like the unix-file permissions? (owner-group-others: read, edit)
Mushon Zer-Aviv | Shual.com - design studio | ShiftSpace.org - an opensource layer above any website | + 1-646-283-6057
This is a very interesting idea. The permission model have proved itself well in server level viewing/editing and might work for us here too.
What I am asking myself here is about yet another issue...
We might not want to exclude users from viewing something but would like to address specific users/groups.
Meaning, if in a public space like the subway I am talking to a friend, I might choose to either whisper in her ear or talk in a way that others can listen on if they want. Either way my communication is contextualized by the fact I addressed someone specific and whoever might listen in would know they are not prohibited from listening but might just not find it necessarily interesting. This addressing thing should obviously be emphasized in the interface (both in authoring and in browsing shifts).
So shifts might have 6 levels of relevancy for me as a 'reader':
Apart from that, I like the idea of group editing of shifts but it might work well with building a whole wiki functionality around it. I currently think group editing is a bit further down the line, while getting addressing, group viewing and shifts comments makes more sense as an earlier step.
more thoughts?
Mushon Zer-Aviv | Shual.com - design studio | ShiftSpace.org - an opensource layer above any website | + 1-646-283-6057
So; if we would have a shift 'myShift' the attributes for it could be:
owner: me
groups: myGroup
permissions for: owner, groups, others
0=none
1=read
2=read/edit
then, taking your scheme;
> Invisible - I am prohibited from viewing the shift
(I'm not in the group, nor owner so 'others'=0)
> Not for me - I am allowed to view the shift but it was not
> addressed at me.
(I'm not in the group, nor owner so 'others'=1)
> General - this is a general shift to the wide § user base
(others=2)
> For my Group - the shift was addressed at a group I'm a part
> of.
(group=2)
> For me personally - This one was aimed for me, probably a
> friend believes I might find it relevant (while others might
> or might not be excluded from viewing it)
(others=1)
> Private - Only I can see this shift, a note to self of sorts,
> or a shift draft.
(group=0, others=0)
I see here that it might seem necessary to create a possibility to
'flag' a post for a specific person or group, but that is not something
I think should be part of the permissions. If we think about ShiftSpace
as an architecture, like the www is, the functionality to tell someone
about a relevant website is not part of the website itself, but done
through eg. e-mail.
Analogue to the classical setup that governs the internet, a shift could
only have 1 group, if others can read the shift the can copy it to their
own shifts and become owner of that copy. Then assign a different group
to the copy.
If we however want to try and embrace a more liberal decentral structure
like the internet was initially envisioned we could have a wiki-style of
editing shifts if 'others' is set to read/edit (2). Then, if a shift is
part of two trails, and edited by one; it will also change for the other
trail.
On Tue, 2008-04-15 at 10:15 -0400, Mushon | Shual.com wrote:
> This is a very interesting idea. The permission model have proved
> itself well in server level viewing/editing and might work for us here
> too.
>
> What I am asking myself here is about yet another issue...
>
> We might not want to exclude users from viewing something but would
> like to address specific users/groups.
>
> Meaning, if in a public space like the subway I am talking to a
> friend, I might choose to either whisper in her ear or talk in a way
> that others can listen on if they want. Either way my communication is
> contextualized by the fact I addressed someone specific and whoever
> might listen in would know they are not prohibited from listening but
> might just not find it necessarily interesting. This addressing thing
> should obviously be emphasized in the interface (both in authoring and
> in browsing shifts).
>
>
> So shifts might have 6 levels of relevancy for me as a 'reader':
>
> 1. Invisible - I am prohibited from viewing the shift
> 2. Not for me - I am allowed to view the shift but it was not
> addressed at me.
> 3. General - this is a general shift to the wide § user base
> 4. For my Group - the shift was addressed at a group I'm a part
> of.
> 5. For me personally - This one was aimed for me, probably a
> friend believes I might find it relevant (while others might
> or might not be excluded from viewing it)
> 6. Private - Only I can see this shift, a note to self of sorts,
> or a shift draft.
> I think we can make the notifier emphasize these levels of relevancies
> and by that make shift making a more meaningful communication tool.
>
>
>
> Apart from that, I like the idea of group editing of shifts but it
> might work well with building a whole wiki functionality around it. I
> currently think group editing is a bit further down the line, while
> getting addressing, group viewing and shifts comments makes more sense
> as an earlier step.
>
>
> more thoughts?
>
>
> Mushon Zer-Aviv | ע Shual.com - design studio |§
> ShiftSpace.org - an opensource layer above any website |
> + 1-646-283-6057
>
>
>
>
> Mushon | Shual.com wrote:
>
>
> > Here is the second proposal posted by the newcomer Michael van
> > Schaik and worth of discussion here on the discussion list:
> >
> >
> > - Design & implement group-structure for collaborations / interactions;
> > In order to collaborate, users should be able to form groups that can
> > work together on trails & shifts. Shifts could then be owned by users
> > and groups, and have permissions set for this like the unix-file
> > permissions? (owner-group-others: read, edit)
> >
> >
> > What do you guys think?
> > --
> >
> >
> > Mushon Zer-Aviv | ע Shual.com - design studio |§
> I see here that it might seem necessary to create a possibility to
> 'flag' a post for a specific person or group, but that is not
> something
> I think should be part of the permissions.
Yeah, I agree with this. I like both ideas (Unix-style permissions &
gradients of addressability). They are both familiar, simple, and
would provide some badly needed tools for cooperation within §.
-Dan
I have discussed it off list with An and Michael (separately), recapping and mainly musing on here.
I think the unix permissions paradigm is a useful one to a certain degree.
As long as we know who we mean by 'group' it works, but we might have multiple groups and then things become more complicated.
I think that before we run to open every aspect of shiftspace, we need to make sense of what we have.
IMHO I believe the current communication model that ShiftSpace offers is flawed as while it does a great job of announcing to whoever wants to listen, it is not very useful when it comes to discussion. For example:
Mushon Zer-Aviv | Shual.com - design studio | ShiftSpace.org - an opensource layer above any website | + 1-646-283-6057
an wrote:
711 Best, An --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "ShiftSpace" group. To post to this group, send email to Shift...@googlegroups.com To unsubscribe from this group, send email to ShiftSpace-...@googlegroups.com For more options, visit this group at http://groups.google.com/group/ShiftSpace?hl=en -~----------~----~----~----~------~----~------~--~---
1. First priority is communication tools, to make Mushon's use case
possible
2. Second is controlling visibility to a greater extent (restricting
read access in new ways)
3. Third is collaborative tools (expanding write access in new ways)
Permissions done in the Unix style could potentially hit 2 & 3 in one
shot, but the main point is we should focus first on the communication-
oriented stuff. I don't know about the multiple groups thing -- sounds
like it'd be more trouble than it's worth.
Thoughts?
-Dan
> Mushon Zer-Aviv | <shual_icon.gif> Shual.com - design studio |
> <shiftspace_icon.gif> ShiftSpace.org - an opensource layer above any
Right now the data elements are pretty basic, so if we face the very
serious task of trying to create a distributed model of the db, i think
it will be easier for us to tackle this problem with current entries,
tools and spaces. If we create a permission system prior to the
distributed model, i suspect we will have to backtrack allot in order to
solve the issue of data integrity and permissions on the distributed model.
We wouldnt want to cut off features for the sake of reliability, rather
we would want to build the features on top of a better structure.
IMHO we need to polish all the elements we have for 0.11 possibly
perfect them to 0.12 and start working on the distribution issue
Im a paranoid minority so forgive me :)
D
In any case, yeah, let's put these discussions on hold until we get
0.11 out the door and the new server is operational. I'm about to head
out to Eyebeam for the hacking session today, which I think will be a
good one.
-Dan
> Another choice I've been exploring more
> recently is Jabber.
Oops, I mean ejabberd -- Jabber is the protocol, not the software
package.