Sugar Network/1.0/Todo

Harmonic Distribution version cycle: | 1.0 | Factory |

0.1

• Users friendly Sucrose+Sugar Network client distribution. Done.

Distribution will be formed as 3rd party repositories to install packages, i.e., something like Sweets Distribution.

Packages will include:

• Sucrose with integrated SN client
• Pre-configured environment to start using SN from server hosted on SL server

So, after attaching this repository, installing one package and launching sugar, people will see current SN implementation and start collaborating on public SN server. Collaboration will include:

• launching activities from the SN (mirrored from ASLO)
• populate already implemented resources, linked to activities, e.g., Questions

Sugar Shell will provide the following options for providing SN content:

• Original Home view (not SN), by default Empty favorites view, will be improved in 0.2;
• Original Home view with activities provided from SN, limited meanwhile solution Favorites view will contain local activities downloaded from SN in 0.2;
• SN client instead of Home View list view.

Switch between Home View modes will happen from Control Panel.

0.2

• Investigate Jabber related issues: [1]. Major work is done, minor issues might be fixed in process.
• Synchronization between SN nodes. No chances to have it in 0.2, postponed to 0.3.
• Server notifications about SN data changes. Implemented on server side, client will use it in 0.3.
• Expose favorited contexts in favorite view in Home view.
• Revise Dextrose-3 patches to exclude ones that don't make sense after enabling Sugar Network. Some bugs fixing commits were merged to SD repositories.
• Prepare .pot files.
• XO images for students and teachers (teachers server).

0.3

• Handle server notifications about SN data changes in client application.
• Synchronization between SN nodes.
• Basic i18n support in SN content (excluding managing already entered strings).
• Basic routines for SN editors (including initial populating SN content):
  • let all people, not only editors, expose the fact that particular activity [doesn't]works in theirs environment (maybe just by exposing how many fail Reports exist for the Implementation, Report might have the level of failure: doesn't do basic work, doesn't do optional work but basic features work fine).
• Since there are useful binary based activities (GC, TuxPaint), support upload such activities to SN. From developers point of view, the only they need to proceed is uploading sources bundle to SN, the rest (building sources for all supported platforms) should happen automatically.
• Revise most popular ASLO activities to add all needed meta information (like required dependencies) and mark the as stable and ready to run from Sugar Network.
• Worfklow to semi automatic collect fail reports using Report resource.
• final XO image, for students and teachers (teachers server), that is ready for deploying.

1.0

• Implement Articles resource, full featured wiki articles (sub-pages, attached files).

Inventory of technical issues outside Client and Server

• How will students register with a teacher
• How will teachers turn their laptop into servers
• What are the constraints of the syncronization mechanism
• Patch to Journal for sharing in SN

Questions for expert

• Should students and teachers be clearly separated in the GUI?
• Should teachers track what their students do within the Network?
• Should the students track what they do within the Network?
• Should teachers moderate what their students do within the Network?
• What kind of users' statistics will be useful for educators/researchers?
  See the current implementation of Australian request. The collected data are being stored in RRD format and might be represented in graphics.
• What kind of users' statistics will be useful for teachers and learners?