Labs/Bespin/DesignDocs/Collaboration
Contents
Collaboration
This is a straw-man for how collaboration might work.
Terms
Projects
All projects have an owner. That owner gets to specify privileges for the project. If projects want to have something shared then they need to either nominate a leader or create an extra 'project' user.
Projects are shared by their owners to a set of users.
Users/Networks
Users have a set of friends. We will use the twitter 'follow' method to make it grow painlessly:
// Currently logged in as jwalker > follow dalmaer > follow kdangoor > follow bgalbraith
You can 'unfollow' someone too:
> unfollow spammer
The principle is that a user can only chat or share with followers (which they don't choose), but they can elect to follow anyone. This does create something of a rock-star culture, which isn't all good, but I suspect that it will help Bespin.
Following someone has the effect that you can see any projects that they decide to share with you. In effect following is bottom up, but sharing is top down. There should be a feedback loop: followers encourage you to share, sharing encourages followers.
Groups
In order to simplify sharing amongst a large sets of users, we support groups. There are 2 special groups: "everyone" and "followers". Groups are an optional feature, however the special groups important for the first release, so I'm describing them now.
Users can group their followers into groups to allow them to manage sharing better.
// Current user is jwalker > group add bespin dalmaer kdangoor bgalbraith fred Created group 'bespin' and added 4 users. > group remove bespin fred Removed user 'fred' from 'bespin' group.
You can remove all users from a group by omitting the usernames:
> group remove bespin Removed group 'bespin'
Groups are automatically created when they have at least one member and deleted when that member is removed:
> group No groups currently defined > group add beatles john paul george ringo > group 1 group defined: 'beatles' > group beatles Group 'beatles' has 4 members george john paul ringo > group remove beatles john paul george ringo > group No groups defined
Groups do not nest, but transferring one groups contents to another is possible
> group add small dave > group add test small User 'dave' added to group 'test'
Special users like everyone/followers can't be added to groups.
> group add test everyone Special users can not be added to groups
You can only add users to groups if they follow you:
> group add test spammer You must 'follow spammer' before you can add them to a group
If you unfollow someone they will automatically be removed from any groups that they were in:
> group 1 group defined: 'test' > unfollow dave > group No groups defined
When there is confusion between a user name and a group name, the group name always takes preference, with a warning. This allows the following:
> group add fred dave > follow fred Warning: You already have a group called 'fred'. References to 'fred' will apply to the group and not the user. It is recommended that you rename the 'fred' group > group add fred2 fred > group remove fred > group 1 group defined: Group 'fred2' has 1 member dave
Users can only follow users, and not groups.
> follow everyone Error: Only users may be followed
Sharing
Project owners can decide to share a project to their network.
A sharing has access permissions:
- readonly
- edit
Each sharing also has a scope of what the invited user can see. This is a flag:
- loadany: The invited user is allow to open any file, if this flag missing, the invited user is only allowed to see what the inviting user has loaded.
Owners can select from any of their friends or from followers/everyone.
// Currently logged in as jwalker > share someproject kdangoor edit loadany
Now Kevin can open open and edit any file in someproject. The only thing Kevin can't do is to change sharing permissions. Only the project owner (Joe in this case) can do that.
Alternatively:
> share someproject dalmaer readonly
Now Dion can only see any file in someproject so long as it is focused on my screen, and then he can't edit it. If Joe closes the file or focus on a file in a different project, Dion's view of Joe's screen will go blank.
If the permissions are left off, the defaults are "readonly". So we could also have said:
> share someproject dalmaer
The permission "none" removes all sharing from that project for that user.
> share someproject bgalbraith none
Ben no longer has permission to do anything to 'someproject'. Any views he has of files in this project will go blank, and he will no longer be able to save changes.
It is not clear to me if 'edit' without 'loadany' is useful. The only time I could see it being useful is where a project owner wants to allow an un-trusted user to point out some changes that they recommend.
Each users "Bespin Settings" project may be shared, but only read-only. This is to prevent the spread of worms through Bespin:
> share BespinSettings someone edit Error: For security reasons, BespinSettings can only be shared readonly
Privacy
Users have a privacy setting for each of their friends. It defaults to closed, but it can be opened up: Allow Kevin to use the view command on me (see below)
> viewme kdangoor true
Make sure Ben can't see me goofing off ;-)
> viewme bgalbraith false
Or the exhibitionist mode
> viewme everyone true
Make Ben's ability to see what I'm doing depend on what the 'everyone' setting is at.
> viewme bgalbraith default
We discover the settings for a person by first assuming closed then applying the everyone setting (unless it is set to 'default'), then the followers setting (if the viewer is a follower, and it's not set to 'default') then the friends setting (if the viewer is a friend, and it's not set to 'default') then the specific user setting (if not 'default')
Examples
Webcast
Amy creates project X, and announces to the world that she'll be giving a demo at a certain time.
> import ... projectx // Runs off to create a blog entry, and then at the right time: > share projectx everyone myview readonly > viewme everyone true
Bill reads Amy's blog and wants to get involved:
> follow amy
This has the side effect of adding Amy's shared projects to Bill's list of projects. However since projecty is shared as 'myview', Bill is unable to dig around inside it.
> view amy
File views opened by the show command are different from other views. They are controlled by the project owner so all viewers see whatever file Amy has open at any time, and the view follows Amy around. In common with normal file views everyone can see the editors and viewers of the current file.
If Bill does 'view amy' when he is blocked by the 'viewme' command, or if Amy kicks Bill off her list of friends, he will see the same blank screen as when Amy isn't focused on anything that Bill has permissions to. That is to say, if Bill can't view Amy, he isn't told why. We might consider telling Amy in a chat message though.
When the webcast is over, Amy will probably want to go off-stage and have some privacy:
> share projectx everyone none > viewme everyone default
Pair programming
Chuck creates project Y, befriends a co-worker, Doug and gives Doug anything+edit permission to project Y, so now they can pair program together. This (perhaps surprisingly) shows off one of the benefits of a user centric approach to projects. There is no confusion over who is going to check the code in. It mirrors what would happen in real world pair programming.
> import ... projecty > follow doug > share projecty doug anything edit
The current project (projecty in this case) is now shared with Bob, and it appears in his list of projects (marked as owned by Chuck)
They can then sit on Skype chatting, or maybe using a hacked up GMail chat thingy in a later version??. They can both edit any part of the project. Some restrictions:
> view chuck
Fails Chuck has not given permission, but if Chuck does:
> viewme doug true
It will work
They can chose an alternative way to to see what the other user is working on. There is a collaboration extension to the load command:
> load -view doug
Doing this will allow Chuck to open whatever file Bob is working on now. If Bob begins editing another file, Chuck can 'load -view doug' again to sync up. If they happen to edit the same file they see each others changes as they happen. Whenever 2 or more users are editing the same file, they all see the names of the other editors/viewers. 'load -view doug' is just a synonym for 'load <whatever-doug-is-looking-at>'
TODO: The algorithm for the viewme command might need reversing - I'm not sure.
Joint project
Eric wants to create a project that works like a wiki:
> import ... projectz > share friends edit
Now all Eric's friends can edit projectz. He keeps his own actions private:
> viewme everyone false
As specified above, this would still allow people with named privileges to view. We're certainly going to need:
> viewme // A report on exactly who can 'view' the current user
And
> share // A report on exactly who can see what of your projects
Chat
I'm thinking that this might not be phase 1. It depends a bit on how much work we think the above is. It's not like IM clients don't already exist, so to a certain extent we're re-inventing the wheel. However there are cases like webcast that would benefit greatly from integrated chat.
I suspect that groups will become far more useful with chat (currently held for release after basic collab) - It's possible to manage sharing to a group manually, but you can't chat to a group manually. If we needed to cut things back then we could take out groups and chat, and do some quick thinking about how 'everyone' is implemented.
It's inevitable that there will be multiple chat destinations. Sometimes people want to talk directly to another user, sometimes to a team, and so on.
I want to avoid the multiple-window/tab mess that most IM clients run into. Particularly in a web browser where display simplicity is very important.
I imagine a chat window where incoming messages from all sources are mixed together. There are 2 options to reply - from the command line:
> msg [destination] [message text]
We might need to add the ability to set a default destination to save keystrokes when there is lots of chatting going on.
Alternatively if the user clicks on a message in the incoming messages section, a 'reply' input box will open just below the incoming message. When return is pressed, the input box will disappear.
It is entirely reasonable for someone to want to work without interruptions:
> msg divert
Will cause messages to be sent over email (TODO: batched?). The sender of a message that is diverted will be informed that the message did not get through. The sender will get exactly the same message if the destination user is logged off.
Destinations
There are a number of places that messages can be sent:
> msg followers Hello, All
This sends a message to anyone that has elected to follow you.
> msg kdangoor Good afternoon, Kevin
Clearly only Kevin gets this, and then only if he has elected to follow me. You can't use Bespin to spam someone:
> follow obama > msg obama Please lower my taxes Error: You can only send direct messages to those that follow you
If you have a view window open, then you can send messages to everyone that participates in that view:
> msg amy -view Could you repeat that last bit?
(Amy being the person giving the webcast above)
If we decide to do groups (see below) then group destinations are also possible:
> msg beatles Is it too late for me to join?
Twitter has had some fairly well publicized performance problems, and we're not attempting to become a twitter replacement. I currently envisage us doing comet routing for users that are logged on, and falling back to email where they are not. Thus we have no database requirements for messages.
Other Notes
We're not thinking that there will be only 1 Bespin. So on one level we might think of a federated model like http://identi.ca/. However I suspect that this is something that we can add in later if needed.
This model is very user centric rather than project centric. It is my belief that projects really live outside of Bespin in Sourceforge/GCode/Github/etc, so we shouldn't be promoting projects as important entities. This follows something of an distributed VCS model which I like.
Is there a need for a "friends" special group?
Related
See also:
