[sugar] Defining Collaboration

[Michael Stone]

Walter wrote:

> Personally, I am of the opinion that the more natural use case is that
> children will engage in short-term joint activity sessions (playing a
> game of chess or a shared record session) but longer-term joint
> project sessions (running a collection of activities--e.g., record,
> browser, write--towards the goal of pulling together a joint report.)

I believe we reached consensus on this use-pattern yesterday when you
stopped by to mind-synch with us. In other words, we agree on the
anecdotes describing instances of collaboration, and perhaps even on
what the human act of collaboration means, but not on the details of the
life-cycle of collaborations.

> We are far from consensus in this, I think that we should be focusing
> on defining persistent work groups with associated chats and common
> workspace (bulletin board) that appear in the group view as a means of
> handling these latter cases. 

I really want to be sure we agree on what the relevant objects are and
on how they relate to one another. Then we can select which pieces we're
actually going to implement. 

To this end, I'm going to offer a more detailed anecdotal description of
collaboration to help flesh out the requirements we might wish to
fulfill. In the process, I'll describe some of the ways I've encountered
digital collaboration. Finally, I'll offer a semi-formal mathematical
description. I offer the latter description because it is the easiest
place to start breaking up the entire notion of "collaboration" into
implementable pieces in a controlled way - we can then literally
describe the "shapes" of the collaborations we actually wish to
implement.

> I don't think we need to do much more that what we already have for
> temporary share activities; they are by their nature ephemeral. 

As my twin descriptions hopefully point out, there is disagreement that
synchronous collaborations are ephemeral; instead, there is a feeling
that they are recurrent but not continuously persistent.

> (Beyond the ability to advertise to either the mesh as a whole, a
> group, or an individual is enough. 

I think we all agree that this is enough to get a collaboration started;
however, I don't think we're convinced that it's the right way to see a
collaboration through in the faces of changes in collaboration topology
(caused by changes in network topology or otherwise).

> Everything else could be handled with the activity.) 

We still have to give activity authors a clear description of the
kinds of collaboration their activity should enable.

> This begs the question of how you form a group (I believe making this
> process simple is important -- work groups and teams are used a lot in
> the field and we should have a goal of facilitating this). It could
> be, but doesn't have to be, the same mechanism as issuing an
> invitation.

Agreed, but we'll get there quickly once we agree on a description of
collaborations that enables us to usefully reason about the effects of
the different UI choices we can, but are not sure that we should, make.

Michael



Anecdotes
---------

The word `collaboration' refers to the human state of working toward and
encouraging others to work toward a common end. Here are some of the
properties of collaborations. A collaboration may:

  * persist across long durations and across intervals of
    non-communication among some or all of the participants in the
    collaboration. 
  
  * encompass different sets of participants at different times.

  * encompass diverse and heterogenous subtasks.
  
In this sense, Croquet worlds, shared activities, and Git repositories
are useful digital reifications of what I mean by `collaboration',
though the means of participation that they enable have fairly different
temporal properties, e.g. some,

  like Croquet and our activities allow two or more participants
  to work `synchronously' on a either the whole collaboration (Croquet),
  or a single part of a collaboration while some, 
  
  like Git repositories, instead allow collaboration participants to
  work safely and easily on different tasks in parallel and further
  allow them to enjoy or avoid divergence as they see fit, thereby
  achieving robustness in the face of changes in network topology and in
  the face of asynchronous (i.e. not-at-the-same-time) collaboration.

In terms of implementation properties, these three implementations each
support a several of:

  a) the ability to maintain effectively continuous consensus on state, 
  b) the ability to allow divergence of state,
  c) the ability to function robustly across changes in collaboration
     topology (which are a superset of changes in network topology)
  d) the ability to manipulate heterogenous state
  e) the ability to support "by-name" as well as "by-value"
     relationships between documents.

  
Activity sharing appears to me to directly offer (a), and conceivably
(d) through the ability to share multiple activities simultaneously but
it eschews both (b) and (c) and certainly (e).

Croquet appears to me to solidly and completely support both (a), (d),
and (e). I believe it could be straightforwardly extended to support (b) if
this has not yet been done. I am uncertain of its ability to support (c)
without relying on a single, persistent, authoritative copy of the world
state.

Git intentionally eschews (a) because, as a distributed source code
control system, it was designed from the beginning only to support (b)
and (c). It has partial support for (d) by virtue of its ability to fall
back to treating data it doesn't understand as opaque binary blobs and
has recently grown some support for (e).


Mathematics
-----------

While informative, these descriptions of some known means of
collaborating fail to pierce to the heart of what collaboration is. More
abstraction seems to be required in order to get a useful handle on the
whole situation. Hence, I propose that:

1. A `collaboration' as a connected surface (i.e. a connected
   topological 2-manifold) parameterized by time. The points of this
   surface represent or can be mapped to some atomic notion of local
   state that cannot be further subdivided, i.e. an opaque integer.

The purpose of this description is to be able to concisely describe
relevant actors (i.e. people, documents, networks, time, etc.) as
appropriate subspaces of this surface or as posessing or manipulating
the state described by an appropriate subspace of the surface.

2. A `subcollaboration' is just a connected subsurface of the main
   collaboration. 

3. The `knowledge' of individual participants or groups thereof can be
   represented as subcollaborations. 

4. The `focus' (i.e. the sites of participation) of individuals or
   groups or can be described as a subcollaboration of the collaboration
   representing the group's knowledge over some span of time. 

5. The connected components of any given time-slice of this surface
   describe islands of network connectivity at that time.

6. `Worldlines' are paths in this space whose time-coordinate increases
   monotonically and these paths usefully represent the state of
   individual documents. 
   
7. `Synchronous collaboration' on a document means that two individual's
   focus-surfaces intersect in a subcollaboration (that likely contains
   a segment of a worldline). 
   
8. `Parallel collaboration' means that two individual's
   knowledge-surfaces intersect in a subcollaboration (that likely
   contains several worldlines which may themselves intersect).
    
Finally, note how this gives us a nice model for divergence because it
says that two (or more!) worldlines that intersect are, for the duration
of their intersection, identical and, when they diverge as lines, they
diverge as documents, perhaps later to be rejoined (merged).