Talk:OLPC Human Interface Guidelines/Activities/Activity Basics

A couple of topics that appear to fit on this page, but weren't addressed:

Forking Activities

Can activities be 'forked'? (e.g. starting a new drawing of your own based on an existing drawing instead of resuming the original) What would trigger such forking? (e.g. would going back and resuming a 'kept' version of an activity be enough to create a new fork?)

This is an interesting question. At the moment, I think we're assuming that implicit forking happens if a child edits a kept version without the entire group that originally created it. That is, in order to prevent the need for complex merges, the two versions are treated as independent objects. The question remains, however, if there should be an explicit forking mechanism, through which a single group which is perhaps still within the same classroom, and therefore still connected on the mesh, can force two separate versions and split into two groups. - Eben 10:48, 13 December 2006 (EST)

Regardless if the forking is explicit or implicit, would it be possible to 'force' a merge? For example a group of kids do something together, and then have to split (maybe losing connectivity or availability) but will keep at it individually. When they meet again, they'll probably want to somehow put it back together into a final version probably mixing or cherry-picking the changes...--Xavi 10:55, 13 December 2006 (EST)

In the absence of any good merging algorithms (since this becomes extraordinarily hard with anything other than plain text - and even most plain text merges are optimized for code where the fundamental unit of distinction is one line), we are presently choosing the simple solution, which is to make manual merges by resuming both instances side by side and then copy/pasting the modified parts. A bigger concern, then is to create object formats that support simple copy/paste. With an image, for example, good use of layers (even if they are transparent o the children) allow a nondestructive form of editing that also makes this kind of merge simpler. - Eben 11:09, 13 December 2006 (EST)

Locking Activities

Can activities be locked to 'current members only'? (This would allow the activity restriction to work properly - lock it to current members first to prevent new entries, then narrow the scope further as people leave. Otherwise new members might join as other members leave, making it difficult to narrow the scope of access)

My present thoughts are actually that the scope of an activity can be limited, at any time, to prevent those outside that scope from joining. The scope, therefore, determines who can join the activity, and not who can participate in it. A child outside a newly defined and more limited scope can remain in the activity until they choose to leave, but once they do the new scope will prevent their re-entry. (In such a case, I would imagine an implicit fork would happen if they tried to open it again. They shouldn't be restricted from opening it, since they have a copy of the object, but without permission to join the current group on the mesh, they open a new revision in their own scope, perhaps. We'll need to think this through more.) - Eben 10:48, 13 December 2006 (EST)