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 (0.1)
    General questions about Contexts. The idea is populating the knowledge base for the Context, similar (but much simpler) to stackoverflow site.
  • Idea (0.2)
    Any ideas regarding Contexts.
  • Problems (0.2)
    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.
  • Solution (0.3)
    Object represent exactly a solution for particular Question, Idea, Problem.
  • 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).
  • Report (0.25)
    Semi automatic reports created if Sugar activity failed to start/stop.
Workflows

From users point of view.

  • Browse Contexts (0.1);
  • Bookmark Contexts (0.2);
  • Launch Contexts as Sugar activities (0.1);
  • Support online and offline modes where in offline, only selected Contexts will be accessible (0.3);
  • Create Questions, Ideas, Problems (0.2);
  • Browse and create Solutions for Questions, Ideas, Problems (0.25);
  • Comment objects (?);
  • Semi automatic creating Reports (0.25);
  • Subscriptions to events for particular Contexts (?);
  • Visually expose already visited content [1] (?)

From point of view of people who can help with solving problems.

  • Browse and create Solutions for Questions, Ideas, Problems (0.25);
  • Subscriptions to events for Contexts people are responsible for (?);

From content creators/uploaders point of view.

  • ASLO activities will be delivered from Sugar Network (0.1);
  • Create new Content for Sugar activity (?);
  • Create new Content for arbitrary document (.xol, PDF, HTML, etc) (?);
  • Upload new versions (?).

From point of view of people who are willing to take part in quality assurance (QA) process.

  • ..

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: [2]. 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. Moved to 0.25.

0.25

Release targeted to getting initial feedback from teachers in Comas district in Lima.

  • Continue working on client GUI improvements;
  • Initial implementation of Solutions in client GUI;
  • Make it possible to create new Reports in GUI after getting Sugar activity failed;
  • Client application needs to reflect on server side changes to avoid showing stale data; Postponed for 0.3.
  • XO images for students and teachers (teachers server) to start testing the system right after flashing XOs.

0.3

  • Consider running the system in Fedora-11 (current in use in Peru).
  • Distribute base software updates.
  • Start gathering usage statistics.
  • Define/Document some useful usage indicators for SN interaction.
  • More useful client behavior in offline scenario, e.g. show content accessible locally. Initial implementation in place.
  • Optimize current implementation to make it more useful on XO-1 laptops. The second shell start (after calling sugar command and before appearing Journal icon) for 40 installed activities is only 6 seconds longer than with Dextrose-3.
  • Setup -testing server instance that will keep regular SN content that should be migrated to new code base on every release.. Sugar Shell looks for http://api-testing.network.sugarlabs.org by default, there is also read-only public web server, http://network-testing.sugarlabs.org.
  • 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): 0.3 will contain only trivial and ready use activities, the editors workflow implementation work will start from 0.4.
  • 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. Moved to 0.4.
  • 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. Thanks to satellit, testing server contains only activities that start without problems.
  • Worfklow to semi automatic collect fail reports using Report resource. Move to 0.25.
  • final XO image, for students and teachers (teachers server), that is ready for deploying.

0.4

  • 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.
  • CRUD workflow for SN content.
  • 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).

Statistics to gather

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?