Content meetings

see also talk:library, game development meetings, software meetings

A more complete list is available at http://laptop.org/teamwiki/index.php/Team:Content_meetings

7 Aug 2007

Tues Aug 7, 2007, 2pm EST, on #olpc-content. add to agenda. to be present: paur, lauren, sj, mel, (kim?)

• next meeting :
• report from Wikimania - wiki, community, loc updates
• check-in on Activity & Library grid, XO and server collections
• reconnect re repository/server dev, PM, wiki farming

  Renaud Gaudin, Mali (offline editing/synch internship)

  fourkitchens

  descriptions

• bundles

  collection sizes & C drop

• l10n priorities

1. curation structure

• pe,pn,ur,eth ---> spanish-language curation, model a spreadsheet for them
• compare br v ng
• scripted curation from repositories, suggest priorities

2. server structure ---> specs & processes.

• repository definition & use case ---> how to add to it? how to partition?
• download and distribute locally.
• making something available to a full class
  • how to queue requests?

3. upload/download library content

• web form for creating cats
  • web intern / UROP / NE

 link/feature freeze M  ===>  code freeze 8/27  ==>  9/xx?
 country dep A : no mats provided; multiling bundle.
 country dep B : 9/30
 extended bundle activity; update via net; v-chat:?  mesh UI?

 assume we're not getting a server build to burn - how much should we do to extract some of it? calendars & schedules
 devs: detail testing.  others: do large testing.  general test plans, cf. test group release notes on [[test issues]]
 smoke testing -- browser tests (video, audio, library)

30 July 2007

Monday July 31, 2007, 2pm EST, 2AM Taipei, on #olpc-content. add to agenda. to be present: paur, lauren, sj, mel, (kim?)

• setting a time for regular meetings
• quick report on Wikimania; any requests from SJ and Mel (who will not be sleeping, apparently)
• check-in to make sure we have an easy place for Taipei Jam contributors (& others) to upload content - Library Grid not the most friendly thing in the world at present
• touch base re hiring (specifically re PM and server developer)

school servers

have a lot of disk space; useful as supernodes; shouldn't be required in general for services to work

• weekly discussions of implementation
• currently: no readily accessibly crypto signing
• libraries: preshipped, modular components added by hand

content stamping

working on this: Adir Abraham

• use cases: world at large

data store

July 5

Who gets to write to the data store?

Some of this is still up in the air. Interesting use cases:

• an activity wants to store something to the data store that is public and sharable. How can the store something in the data store and tag it as sharable?
• There's currently a "share activity" / "collaborate" button that shares a current document. Implications need to be worked out.
• We need an indicator of 'state' -- whether one is working in a shared or private state at a given moment.

Use cases:

• mesh board (distributed craigslist) -- as soon as you 'share' or 'publish' a new announcment, it is stored as something shared.
• Can something on the level of the presence service offer distributed content or other pervasive services that store data using the tag and permission features of the data store? should there be something similar but separat with different security implications for scratch-type store and forwarding? (see below)

Store and forward : Whether or not you use store and forward, there are times when you want to communicate with someone who isn't online.

• Imagine sharing distributed content across a loosely connected network.
• Can this use scratch storage on the laptops? Or another 'directory' in the data store?

Asynchronous notification: We need a style guideline for notifying someone that things are happening related to their interests outside the scope of the current full-frame activity

• notify people when they get responses to their efforts in a particular arena (say, board postings, or shared items further edited by collaborators)
• this can also be useful for doing semi-persistent sharing of files and other assets across the mesh.

Activity-level daemons : There's no spec yet for defining user-level activity daemons, for something persistent.

• Does a data sharing service need to be at the presence level? If so, we may need to provide a UI for turning this on and off.
• Do we need sth like a python libevent dbus loop to allow cheap addition of persistent service daemons?