Collaboration Requirements

Greg Smith gregsmitholpc at gmail.com
Thu Jul 31 10:16:11 EDT 2008


Hi All,

Thanks a lot for all the comments.

I tie up a single response and I edit the requirement as needed. Let me 
know if I don't respond to something you think needs further discussion.

I put the updated version in the wiki 9.1.0 Collaboration requirements 
section: http://wiki.laptop.org/go/9.1.0#Collaboration

***********
First Michael:
 > This feels very similar to an RFC.

GS - Its not meant to be an RFC (AKA a standard that multiple 
organizations adhere to for better interoperability). Its meant to be an 
explanation of what the users require to be successful. Hopefully 
organized in a way that is actionable by developers and QA.

 > should really be citing collaborative systems
 > (both digital and otherwise) from which we take our inspiration and
 > our warnings.

GS - Sounds good. I was giving my background but send over any examplars 
  you want people to know about.

 > no opportunity to fix critical collaboration bugs in 8.2.0 proper.

GS - OK. Its a requirement for 9.1.0. I hope 8.2.0 supports one or two 
collaboration examples with all the relevant details down to the 
activity level. I'm not giving up on that yet.

 > We're actually on the trailing edge of collaboration technology

GS - I added your apps to the background section. Maybe we should call 
ours "real time" collaboration. Agreed were behind in sharing data. Now 
tracking that in file management section of 9.1.0. 
(http://wiki.laptop.org/go/9.1.0#File_Management) but could be renamed 
or may deserve new section. My tendency is to make it a top priority in 
9.1.0.

 > Please define "support" before using it here.

GS - I mean tested and shown to work. Added to wiki version.

 > I'm not sure that your priorities are correct. (re S1 - S4)

GS - Quantify your position with # of schools or kids and we can change
it. The key point is to support one of them. Then we can tell 
deployments to build it that way if we have a documented and tested 
solution.

 > You need to be more precise here. (re: N2 RF environments and other 
comments on RF.)

GS - OK. Give me new wording. Make sure its something users can measure 
with available tools in the field and QA can test. Cover physical space, 
traffic on other radios or whatever you think is relevant.

 > Is N10 different from N9 only in that in N9, non-collaborating users
 > have been explicitly asked to avoid intentional network actions? (and 
N8 - 10 comments)

GS - N10 v N9 refer to the same steps by kids but different network 
architectures (S1 v S2). May not need both. N8 is intentionally easy. 
Worst case we tell everyone to shut down and then it works for 10 kids. 
I wanted to throw in one freebie :-)

 > "Allowable scale" is conditioned on parameters that you are not fixing
 > in your requirements. You need to specify those parameters.

GS - Scale is defined in the scale section. Let me know if that is not 
precise enough or propose new wording.

 > Beware of collaboration scenarios which give access to state that is
 > larger than the capacity of any single XO. (and chat question)

GS - Not part of this requirement, maybe next time. Chat refers to the 
activity we ship now.

 > You're not aiming high enough.

GS - When can you support this? Give me a date and I'll consider 
something more ambitious next.

**************
On Poly and Martin D's comments re: how to get agreement on a new 
architecture.

GS - I chatted with Michailis about this. He suggested we try to reach a 
consensus on a design or on specific components (start a wiki page 
and/or work it out on the list). If this "community" is in a agreement 
that will move the ball forward. HTHs. Try again if that doesn't address 
your questions.

*************************
On Gary and Martin D's comments re: "eat your own dog food" (harsh 
saying we had at Cisco meaning use your own product)

GS - Good idea if it helps us build something useful more quickly.

**********************
On Ricardos comments:
Sounds good to me. Looks like you are proposing some design and test 
strategies. That's great!

My only comment is that in the end it has to become a set of 
instructions that the user can execute. e.g. chat with 10 XOs, in a low 
noise environment (can be specified precisely) and it will work great! 
If it doesn't work we say: you have too much noise, check your 
neighborhood view and if there are any APs there, find them and turn 
them off.

In short it has to be deployable!

My third favorite e-mail of the year (after "gun-toting bit heads" and 
Alan Kay on the early days) is this one from a teacher trying to use 
collaboration in a second grade class:

http://lists.laptop.org/pipermail/olpc-sur/2008-May/000118.html

" Todos visualizaban a medida que escribían un cuento y les encantaba, 
les parecía mágico."

"Everyone watched while they wrote a story [together] and they loved it, 
it seemed like magic"

Then "se cerró EL PROGRAMA SORPRESIVAMENTE ,¡QUË DESILUSIÖN!!!!" due to 
#7444. Which is why I put in a section about saving files.

I want to get that magic back ASAP, regardless of the gory technical 
details needed to get there. I hope that's clear from the requirements.

Thanks,

Greg S







More information about the Devel mailing list