Sugar Network/1.0/Todo

Harmonic Distribution version cycle: | 1.0 | Factory |

Features

This is a list of features that need to be implemented during the intermediate releases. In brackets, there will be mentioned intermediate releases that when particular feature needs to be initially implemented (obviously, that implementation needs to be polished until final 1.0 release).

Sugar Network

Features related to Sugar Network implementation.

Object domain

The detailed information about Sugar Network object domain might be found on concept pages and in objects model. But in short, Sugar Network objects are represented by the following list (object names might not be exposed in final GUI):

• Context
  These are the top-level entities that represent content in the Sugar Network and might be several types:
  • Sugar Activities (0.1),
  • .xol files (0.3);
  • arbitrary documents that might be opened by the Sugar, e.g., PDF or HTML files that represent, e.g., books (0.3);
  • (this list might be extended before releasing 1.0, e.g., by editable Wiki articles).

The rest of objects directly or indirectly associated with Contexts.

• Question
  General questions about Contexts. The idea is populating the knowledge base for the Context, similar (but much simpler) to stackoverflow site. (0.1)

• Idea
  Any ideas regarding Contexts. (0.2)

• Problems
  Report a problem with Contexts. A user-friendly interface to complain about an error that the users encountered when working with the Context. It is not intended to be a full functional bugs reporting system, but rather a users friendly interface to ask questions. For real bugs reporting case, there is semiautomatic Report object, or experienced people can use already existing bugs reporting systems. (0.2)

• Solution
  Object represent exactly a solution for particular Question, Idea, Problem. (0.3)

• Review
  A post that reviews the Context. (?)

• Comment
  Short comment for existing Question, Idea, Problem, Review object. If you have a post with more than a couple of lines, consider creating new object instead of commenting existing one. (?)

• Artifact
  Object created within the Context:
  • Activity objects, (?)
  • (this list might be extended before releasing 1.0).

Workflows

From users point of view.

Intermediate releases

More detailed TODO list for particular intermediate releases according to the roadmap.

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. Right now, Home view shows activities from ~/Activities.
• 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. Moved to 0.3, translation.sugarlabs.org process should be setup before 0.3 release.
• XO images for students and teachers, teachers server. This downstream work Will be done within the Hexokinase project.

0.3

• Setup translation.sugarlabs.org translation process.
• 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.

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?