Labs/Bespin/DesignDocs/Collaboration

From MozillaWiki
< Labs‎ | Bespin‎ | DesignDocs
Jump to: navigation, search

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: