Feature roadmap

  This page is monitored by the OLPC team.

Overview

This page lists all well defined feature requests for XO. Some of these feature will make forthcoming releases and some will not. They will be flagged for a release and listed on the corresponding release page as they get prioritized, scoped and filled in. This page is meant to be abstracted from releases and it should therefore include a superset of priorities for any given release.

This page goes hand-in-hand with the Feature requests page, as follows:

1. Feature requests

Features, requirements and requests by country. This page contains verbatim requests from technical leads or translated and reviewed rewrites of initial feedback. Only items specifically requested by a qualified technical lead, administrator, teacher or student in the country should go in this section. See also: Deployments

2. Feature roadmap

Feature suggestions by technical strategy. Each item on this page should include reference to the;Requester: (e.g. country or engineer or URLs to relevant discussions and sites). It should also include a reference to which element of the strategy it fits in to (if available).

The next release is 9.1.0 planned for posting in March, 2009. Weekly meetings for 9.1.0 planning are held on Wed. at 2PM US ET on IRC - freednode.net #olpc-meeting channel

Suggestions for providing input

1. Please sign in to the wiki when updating this page and its subpages so we know who made the edits.
2. Raw, unfiltered feedback from countries and deployments should go on the Feature requests page.
3. Feel free to add to this page following the guidelines described above. You can add a subsection to #General comments below, or add to this page's discussion page.
4. To comment on a particular feature, click the feature's title to go to its subpage, then click its discussion tab comment on its discussion page.
5. Before editing the subpage for a particular feature, , discuss your edits with the original poster /owner beforehand.
6. You must use the template correctly when requesting features or enhancements, otherwise your feature won't show up. Follow #Adding to the roadmap carefully
7. Use <trac> when referencing tickets/bugs.
8. Additional suggestions for providing input are welcome.
9. Create a new section (At the == header 2 == level) for your country or request if none present are adequate.
10. Make sure all ideas have a very solid basis for being valuable to customers. Including links to blogs, reports or other data that proves users really need your feature will make a big difference.

Roadmap

Adding to the roadmap

This section lists major features to be added to XO software over time. When adding a new feature please follow thee guidelines.

1. Make sure the feature doesn't already exist
2. Read the Usage section of Template:Feature tracking for help filling out the template on the new page
3. Pick an "Feature subcategory" from Category:Software features
4. Find the requester(s)' wiki pages and the feature owner's User: wiki page
5. Follow the OLPC:Style guide for page names, change Good feature name to your new subpage title.
6. Ready? Click the button below to create a new meeting wikipage with the right title convention that's prefilled from Template:Feature tracking/Preload, edit it to suit, then save. After a delay (due to wiki query and page caching), your new subpage will appear in lists of features.

<inputbox> type=create preload=Template:Feature tracking/Preload buttonlabel=Create a new Feature roadmap subpage. default=Feature roadmap/Good feature name width=40 bgcolor=#f0f0ff </inputbox>

A description of each field is listed here:

Name

A brief, one-line summary of the feature, used as the title on the page

Requesters

Deployments, engineers, or both who support the request

Requirements

User level requirement definition; Links to detailed wiki pages, mailing list threads, or other resources are welcome

Specification

Design and technical implementation ideas; Links to detailed wiki pages, mailing list threads, or other resources are welcome

Owners

Names of developers and/or champions of the request who will ensure that progress is made

Priority

1-5 (1 = Critical,2 = High,3 = Medium, 4 = Low, 5 = not needed)

Helps deployability

yes or no Better deployability is the goal of 9.1.0. Tag this field if it helps that, regardless of the "target 9.1.0" status.

Target for 9.1

yes or no When this field is set to true, it means that and OLPC engineer is (or will be) assigned to work on this for 9.1.0 release.

See also: general suggestions for providing input.

All features

Click on the arrows in any heading to re-sort by that heading. {{#ask: Short name::+

 |?Is part of=Area
 |?=Feature page
 |?Requested by=Requested by
 |?Helps deployability
 |?Target for 9.1
 |?Contact person=Owner(s)
 |?Priority
 |sort=Is part of
 |mainlabel=-
 |limit=200
 |default=Nothing found in Category:Software features with Property:Short name?!

}}

Other queries

See Features-test, or you can write your own.

Historical

/Archive/pre-9.1.0 has a static copy of the Roadmap as of 2008-12-11, before it was separated

Priorities from Engineering

This section is being deprecated! Please move all your feature requests to the section above. Make sure to include a Name, Requester, Requirement, Specification and Owner. If you don't have all the info, fill in what you have. I have started migrating these items and removing them from below. See the discussion page for a record of my edits. Thanks Gregorio 18:01, 4 December 2008 (UTC)

• #2188 sharing files and resources between activities
• #1496 Switch to real public keys - Scott
• #8170
• #8171
• #8177

Less flickering in starting activities and other screen changes - Michael

Ensure the blinking of the lights is meaningful.
http://lists.laptop.org/pipermail/sugar/2008-September/008237.html

Backup to Internet idea from Walter:
http://lists.laptop.org/pipermail/sugar/2008-September/008340.html

Sugar architecture ideas

From thread started by Michael S
http://lists.laptop.org/pipermail/sugar/2008-July/007304.html

e-mail from Ben S

http://lists.laptop.org/pipermail/sugar/2008-July/007390.html

1. The datastore

Sugar's design calls for a centralized rich data storage system, the datastore. The datastore provides secure, limited file access to Activities, manages file metadata, maintains a differentially compressed history of all work, ensures reliable backups to a trusted server, and mediates the connection to removable media. Every one of these features is crucial to Sugar's functioning, and almost none are really working at this time. We cannot afford another release based on the present datastore, as it fails to implement the features we require, and is unreliable even in the features it supposedly implements.

Solution:
There have, at this point, been at least five distinct proposals for a next-generation datastore design, all differing in underlying implementation and user-facing functionality. We need to have a Once And For All datastore summit, draw up a compromise datastore design, and implement it. We can do this by 9.1.0, if we are willing to make it a priority.

Additional Links:

• The current datastore
• Olpcfs
• Sugar Datastore Summit in January (item 10).
• SDS (stands for Simple Data Store or possibly something else)
• Git-based datastore desig

4. Activity modification

A keystone of the Sugar design has always been the user's ability to edit any Activity, and to cement this a "View Source" key was designed right into the hardware. This functionality is simply missing, and that prevents us from making our principal claim regarding an emphasis on user modification.

Solution:
"Develop" must be polished, finished, and included by default. This will require modifications to the core system, in order to support an endless variety of slightly modified Activities. It will also require work on the Develop program itself. If volunteer efforts are not moving fast enough, OLPC must ensure that someone is working on the problem as a professional.

Additional links:

• Develop
• Previous, stalled attempt at Develop
• Current status of "view source"
• OLPC_Human_Interface_Guidelines/The_Laptop_Experience/View_Source
• EAG_The_Laptop_Experience:_View_Source

5. Bitfrost

Sugar, as it currently stands, is among the least secure operating systems ever, far less secure than any modern Linux or Windows OS. I can easily write an Activity that, when run by the user, escalates to root privileges and does anything I like with the system. Given Sugar's competitive status against Windows XO, this failing threatens the very existence of the project. The Sugar designs have long stated that safely running untrusted code from a classmate is a key goal for learning, but the current software accomplishes precisely the opposite.

Solution:
NO ONE IS WORKING ON BITFROST. That's right. Everyone who was working on Sugar security (after activation) has either left OLPC or moved into another role. Someone must be assigned to continue the security work, or it will certainly never make progress. Anyone who _does_ take on this challenge will start from a much better position than previously, because many of the Vserver features have moved into the mainline kernel over the last few versions. The kernel now contains a number of new, powerful isolation and control primitives.

Thoughts from User:cjb

• Translation of Sugar inside Sugar?
• A working Distribute activity for journal objects (could be in the Journal)

Thoughts from User:Mstone

• Security already contains my immediate security roadmap.
• My user page links to several of my other ideas, many of which are procedural improvements with software components.
• My largest ongoing concern is that we have not yet smoothly carried a deployment through an update to a new major stable release. (Peru may become our first exception to this rule, but this remains to be seen.)