Notes from July 22 visit to computer lab GPA with 3rd graders. 
By Greg Smith 
See all the class notes here: [[Gardner_Pilot_Academy#Class_notes]] 

Came early and talked with Caroline for 1/2 hour about project management strategy. Will send e-mails to sugar-devel lists with follow up on that. Main points:
* There are still some technical issues to be ironed out for the fall (e.g. USB sticks failing, faster boot, booting on Mac and possibly doing without CD). These need to be tracked agressively.
* Lesson plans idea is good but may not have a lot of lead time from lesson plan creation to class start. Will begin by documenting classes we have already held.
* Most likely classes in the fall are 5th (confirm) grade Science teacher doing science notebooks and 4th grade teacher wanting to keep portfolios of work. That said we aren't sure and may not know until Labor day.

Looking at their windows computers (Win2K) I saw that they have KidPix3 deluxe, Kidspiration (by Inspriation SW) and Investigations. The last corresponds to the Investigations curriculum and uses Turtle/Logo. All apps more than 5 years old but very complete and well designed SW. May not be easy to use but they are pretty. May want to follow up with the makers of Investigations SW: Terc - http://www.terc.edu/

I asked the teacher if they have used the Investigations SW and he said no he had heard it was on the computers but never had a chance to try it.

Walter ran the class. He asked them to plug in the USB stick, start the computers and come back the rug. One new kid needed a new USB stick. Not having the same stuff as the rest of the class was very stressful to him. It looked like he felt left out but looked beter once he got booted with his name and color.

Back on the rug Walter asked if people remembered the Memory game. He asked what did we do with it. Kids answered "played" and on prompting added that they created their own games. More prompting and they mentioned creating pictures and getting pictures. W: "where did we get the pictures?" Kids: "Wikipedia" and "Internet".

Back on the computers, Walter started the kids off by asking them to download Conozco Uruguay. Caroline opened Browse on the right page, bookmarked it and shared browse. All the kids opened browse and found the shared link. It takes a little longer than we would like for the share to be available.

Some kids needed to be reminded to look at the bottom of the screen to find the shared bookmark. Other asked where the Browse was. Many asked to be told to click OK after download completed. Some clicked on the "continue" button while it was counting down (I actually never understood the purpose of the count down). After clicking OK, some needed to be shown how to go back to the Home and click on Uruguay. Finding the frame, task switching, understanding "where" you are and how to get to another app is still a challenge.

After opening Conozco Uruguay the kids started clicking on it. Most didn't read Spanish, but they tried it anyway. They liked the rocket getting built. They learned a lot about the the Departmentos of Uruguay! Many looked at it in investigate mode then remember what they saw in quiz mode. Smart kids!

Two bugs seen in Conozco Uruguay:
# Investigate in Topographic mode didn't seem to work.
# Salir button did not exit. Stop button worked.

After playing with it for a while some kids went back to playing with Memory. They opened old memory instances from the Journal although they couldn't easily find their own customized games from there. The Journal entries may have remembered who was playing with who as they seemed to join each others games rapidly and without much conscious effort (except maybe choosing "share with neighborhood"). I have no idea how the "shared" but they didn't worry about it and played away.

Back on the carpet, Walter said that we would be making our own game and asked kids what makes up a game.
Kid asked if they can make a fun game like he sees on Qubo. http://www.zimmertwins.com/ They wanted it to be fun.
Walter opened Write on the projector and wrote down the following (~) from the kids:

What is needed for a game?
* Alien
* Pieces of the rocket
* States
* countries
* English words
* Communities
* Computer
* Airplane
* Jet
* Instructions
* Animation (description by kids, word offered by Walter) and Reward
* Map with labels for borders, states, communites etc. (prompted)

Kid: "is that how you make a game?"

How does a game work?
# Study period to test it out
# First alien asks a question
# Try to answer it
# Alien gives hints
# Get the answer
# Ask another question.

Walter asked them to come up with an idea for their own game. The only constraint is that it should be about something they are learning in Geography

Back on computers kids asked lots of questions went to wikipedia to find pictures, and opened write to start writing down list like above. They started collecting pictures and asked for help searching.

Back on carpet Walter asked each kid to describe their game. Several kids were doing the same thing. They came up with the following:
# Guatemala. Departments numbered and corresponding to images on the map.
# Sports team logos in the US. Then find the state or city for each team.
# Presidents. Match pictures of presidents with names.
# Presidents mashup (word used by kid!). Take a jumbled up a list of pictures of presidents and put them in order.
# Countries and states in North America.
# "Find me". Start with an animation of a spinning globe. Find north america and show that. Find US, find MA, Find Boston, Find Allston, Find Gardner Pilot Academy. One kid yelled out then find the desk in the office.

Post class debrief: 
* Kids liked keyboard short cuts (he had shown them F3). Maybe we should introduce a new short cut each week (next up, alt tab?).
* Kids were comfortable with the neighborhood.
* Kids found and opened Write without any prompting.
* Impressed with how well they learned the goegraphy of Uruguay.
* Task switching is still hard. So is moving data from one app to another.

Discussion of how to make the games they came up with. Modifying Conozco Uruguay may not be easy as it uses an image map startegy (ala HTML Image maps that make hot zones by coordinates). Walter thinks a Geosafari type ionterface is what is needed. (couldn't find an image but its become this: http://www.discoverthis.com/geosafari-laptop-3.html). That is, a map and click on it to find items you are prompted for.

Discussion of need to minimize the "learn a new app" overhead and possibility of using Turtle Art. Walter takes away task of deciding and coding right tool (if only we could have a world class programmer/scientist in every class! ;-)

Next class we can focus on writing the list of things needed in a game and gathering source images. That gives us two weeks to come up with an authoring tool.

2009-07-21T13:58:04Z

Gregorio: /* Types of Requests */

<noinclude>{{GoogleTrans-en}}{{TeamHeader|Sugar on a Stick|home=Project Home|xbgColor=ffe792|join_label=Get Involved}}{{TOCright}}</noinclude>

From Caroline Meeks post, http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg05998.html

I am going to try to answer this, or actually I hope start a brainstorming session that will get us towards a feature list.

I am going to try to use the Customer Role of an Agile process. That means I'm going to try to talk as much about the result I want to see as I can and as little as I can about how to get to it. I do know that some of this is in the works. I also know that some of it will require the heavens to deliver us yet another genius programmer with a new skill set to accomplish by September. But the job of the role of Customer is my mind is to talk about what I'd like to see, what the business case for it is and what the priority is. I hope other people will join me in this role as i think its crucial information for the technical team to have.

==Types of Requests==
[[User:Gregorio|Gregorio]] 13:20, 21 July 2009 (UTC) 
I suggest we break out feature requests in to two types:
# Lesson specific facilitators
# Class management

The first are barriers and bugs to executing the desired lesson plans. The second are tools and technologies to manage many students and allow them to work together. The major headigs below fall in to the second category. We should add any lesson specific bugs or features here as well.

For lesson specific features priority will be given to the following kinds of issues:
* SW is hard to explain and/or its not discoverable so kids need 1 - 1 help.
* SW is time consuming, slow or requires too many clicks.
* Something we want to do is not possible.
* New or updated activity is needed.
* Crash or failure to perform as intended, especially if it entails data loss.
* Class management is too time consuming for the teacher.

Time is extremely precious in class. You get one hour with the kids so every second counts. If something is not clear to kids and you have to explain it to each kid or touch each computer, that is very costly. If it takes 1 minute to show a kid how to do something, there are 20 kids and you have lost 1/3 of your class!

==Solid Collaboration==
* Priority A for [[Gardner Pilot Academy|GPA Project]]. - Defining what this looks like and how we get there is an important discussion and i don't have all those answers. This encompasses local and jabber collaboration.
* Priority(?) Switch on sugar control panel to turn on/off jabber and use only local network for collaboration [satellit07/05/2009]

* Four network configurations are envisioned for use of this feature at GPA:
# Computers on same LAN segment
# Computers on same LAN no VLAN or bridge segment restrictions (aka bug 1012 resolved).
# Computers IP connected to a server inside the firewall only. e.g. School Server in school.
# Computers anywhere on the Internet accessing publicly addressable school server (or any Jabber implementation)

The GPA school will use option 1 above. It will also use local collaboration with no Jabber server. [[User:Gregorio|Gregorio]] 13:20, 21 July 2009 (UTC)

==Straightforward Teacher "Assignment" -> Student -> Teacher workflow==
* Priority B for GPA. For example. Teacher creates a template to scaffold student writing. Students do the writing assignment and the teacher "collects" them. Maybe this happens with Moodle or maybe its done all in Sugar?

==Straightforward Sugarization==
* Priority A for Sugar. By this I mean that a programmer who has created a game for linux or the web could look at our documentation and examples and tell his/her boss, "yes I see how we can make this available for Sugar and it will be a better experience for kids in a classroom through Sugar." Sugarizing should not mean giving up aggregating data for the teacher. It should be a better user experience because: automatic saving, cooler collaboration, easier installation and more consistent performance, easier for teachers to find, available to the million kids with XOs.

==Backup and Restore with School Server==
Sugar on SoaS and Netbooks backs up and restores with XS
* Priority A for GPA,

Now also tracked here: http://wiki.sugarlabs.org/go/Features/Back_Up_and_Restore

==Combine Sugar Live CD, Boothelper, & USB Creator on one image==
* Priority B for SoaS
* Priority(?) Down-loadable Application to clone sugar.iso files and USB sugar on a sticks from a running sugar desktop [satellit 07/05/2009]

==Sugar on a Stick works with a VM==
* Priority B for GPA - it still has to boot on its own also.
* Priority(?)Custom Boot CD with autostart VMPlayer (in sqfs) to run USB "VM's on a stick" on insertion [satellit 07/05/2009]

==A Sugar machine can also run a SoaS ==
* Priority C - Use case. Say you are in a 1-1 Netbook deployment. Your netbook breaks and it'll be a week till its repaired. It would be cool to burn a Stick for that kid from the XS backup and they could then use a teacher's netbook or some kid who is in Gym that period's netbook and still get to participate in the lesson.

==Sugar works on preIntel Macs==
* Priority C for GPA, Priority B for Sugar.

==Sugar works on lesser hardware, say Pentium III 256M==
* Priority C for SoaS

==Avoid surplus Activity launching==
Don't let the user keep opening activities until the machine crashes or is driven to its knees. Make it less likely that a user who is impatient will end up opening multiple copies of an activity.
* Priority C for GPA

==Less cluttered, more consistent neighborhood view==
* Priority C for Sugar

I am copying the Server list because I think many of the things I think are the most important next steps for Sugar require interfacing with, and improvements in the XS.

Priorities are my current opinions and I tried to not bias them with how hard I think the tasks are. They are about how important I think they are, in my opinion, with my customer hat on, to either the GPA pilot, Sugar and its marketing, and partnerships and adoption, or the Sugar on a Stick project. I don't think for a second that things should be done in priority order.

So I hope everyone else sticks their necks out and says what features they want, what the use cases are and what they think their relative importance are. Then we can narrow our focus back down to what we can do for September.

[[Category:Features requested by Gardner Pilot Academy]]

Sugar on a Stick/Goals

2009-07-21T13:20:16Z

Gregorio:

Gardner Pilot Academy

2009-07-20T18:31:49Z

Gregorio: /* 3rd Grade Lesson Plans */

<noinclude>{{GoogleTrans-en}}{{TOCright}}</noinclude>

==Gardner Pilot Academy==
Boston Public Schools - Allston http://www.rabbitnet.net/gpa/

GPA is partnering with Solution Grove and Sugar Labs to pilot [[Sugar on a Stick]].

The Gardner Pilot Academy is the flagship full-service community school within the Boston Public Schools (BPS). The school's vision is to educate the minds and develop the characters of all students in partnership with families and community. To achieve this GPA provides high quality teaching along with a range of social, emotional and enrichment programs delivered by means of partnerships with an array of community organizations and individuals. Over the past twelve years, GPA has developed strong associations with four universities, several health and mental health agencies, the YMCA, and various organizations teaching visual and performing arts. As one of just 20 pilot schools in the BPS, GPA is exempt from district mandates. Therefore, GPA has autonomy in the areas of budget and personnel, along with the freedom to implement innovative curricula, assessments, and interventions.

Located in a culturally and linguistically varied section of Boston, the GPA serves quite a diverse student population. GPA's 336 students and their families speak more than 13 languages ranging from Spanish to Khmer (all of which are supported by Sugar). Demographically, 15.2% are African American, 59.1% are Hispanic, 10.7% are White and 13.1% are Asian. Over 85% of the students meet the federal poverty guidelines for participation in the Free or Reduced Price Lunch Program. The majority of GPA's students fall within a group of students considered to be academically at risk.

GPA is located only a few blocks from Harvard Business School and so is convenient for project development participants who may be students at one of Boston’s many universities.

The school currently has a single computer lab with older computers running Windows 2000. We will be soliciting donations of used equipment from local business to supplement these existing resources. Sugar can be used at all elementary levels and curriculum areas.

==Current computers at GPA==

* A computer lab with about 20 EVO D500 1.7 GHz Pentium 4, 500 MB RAM computers running Windows 2000
* 20 new Apple laptops in a mobile cart (OSX, hardware details unknown, no Parallels)
* Each teacher has a MacBook with Parallels 3.0

There are two teachers in the school especially interested in starting with Sugar:

* 4th Grade teacher who wants to do portfolios
* Science Teacher who wants to pilot with the 5th grade to support a new district mandate for writing in Science

==The Summer Program==

Classes run from July 6 to Aug 17th from 8:30 am to 5pm. The lead teachers over the summer work 10am to 5pm during the school year so we will have good continuity. Here is a [http://www.google.com/calendar/embed?src=t635rhmoabiafhpklue2eoj2lk@group.calendar.google.com&ctz=America/New_York calendar] with GPA events.

They will not be using the mac laptop cart and the summer teachers do not have macbooks.

We will be using the computer lab and we will be talking to the school about putting more computer into classrooms and other locations.

===2nd Grade===

Next Tuesday we will work with the 2nd Graders on their science and social studies. The theme of the week is responsibility and the environment. They will be learning about their community and preping for a cleanup of the local Charles River.

The goal of the first project will be to label a map of where they do the clean up with what they find during their cleanup.

We have half an hour on Tuesday. After kids get their keys and boot up, enter their name and colors we will have them go to Turtle Art. We will prepare maps and preload them on the sticks and show them how to bring them into Turtle Art. Then we'll show them how to have the turtle label them. Next week, after their cleanup they can label what they find on the clean-up.

Maps:
* http://www.paddleboston.com/boston/boston_map.jpg
* http://screencast.com/t/kLcW3O7Tyb4
* http://screencast.com/t/IngjAlCySu

===3rd Grade===

We are hoping that the kids can create a US version of the Uruguay geography/facts game. Any ideas on how to make that easy to do? The vision is they will learn things in class then make them into questions to put into the game. We will meet with the third grade on Thursday afternoons.
===Class notes===
* 15 July - http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg06470.html
* 14 July GS - http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg06412.html
* 14 July AG - http://www.mail-archive.com/iaep@lists.sugarlabs.org/msg05651.html
* 09 July - http://www.mail-archive.com/iaep@lists.sugarlabs.org/msg05561.html
* 08 July - http://www.mail-archive.com/iaep@lists.sugarlabs.org/msg05534.html
* 07 July - http://www.mail-archive.com/iaep@lists.sugarlabs.org/msg05529.html.
* 07 July XS report - http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg06104.html
* 01 July - http://www.mail-archive.com/iaep@lists.sugarlabs.org/msg05416.html

==Looking for Summer Volunteers and Work-Study Students==

We are currently looking for committed volunteers and work-study students for the Summer. We have some funding for Work Study so if you know any eligible students please let us know.

Ideally we would like a team of 3 people, each working around 20 hours per week, consisting of a technical person, a person with education experience and a marketing person.

==Project Goals==

For the GPA School:
* Student Learning,
* Teacher Participation,
* Parent Perception and
* Greater GPA School community perception of the project.

Our goals for the Sugar Project are:
* Sugar on a Stick projects replicated at other schools,
* Improved Sugar for everyone, including OLPC XO children,
* Increased visibility of Sugar, and
* Knowledge and best practices gained for using Sugar in US Schools.

=== More Detailed Sub Goals ===
From our Balanced Score Card: http://spreadsheets.google.com/ccc?key=px5yPvIlUlLtsrYpZdVG_EQ

The Student Learning Section is copied here:
* L1.1 Use of Sugar
* L1.2 Learner Engagement
* L1.3 Extend learning beyond the school day
* L1.4 Students use Sugar to create and explore
* L1.5 Students use Sugar to help create portfolios
* L1.6 Students work collaboratively
* L1.7 Students are proud of their work and feel a sense of ownership
* L1.8 Sugar is supporting learning the curriculum in the classroom
* L1.9 Sugar is supporting exploration and learning outside the curriculum

=== Standard Curriculum ===
Notes on Curriculum from conversation with Assistant principal.

* Fundations for Phonics K-3 - http://www.fundations.com/
* Making Meaning and Being a Writer for 1 - 5 fluency - http://www.devstu.org/being_a_writer/using_mm_with_baw.html
* Investigations for K-5 math - http://investigations.terc.edu/
* Foss program for science - http://www.fossweb.com/

* Massachusetts Curriculum guidelines - http://www.doe.mass.edu/frameworks/current.html

=== Sugar Computer Lab Lesson Plans ===
This section is intended to prepare lesson plans and give details on classroom interactions for the school year starting in September, 2009.

After defining lesson plans here, we can quickly extract SW features and bug fixes which will facilitate this classroom interaction.

==== Context ====
10 - 20 4th grade kids will come to the computer lab once a week for an hour. Each kids gets a USB stick with SoaS and all of their previous work on it. The sticks are kept by the Sugar volunteers and brought back to class each day.

Two teachers and 2 - 4 Sugar volunteers participate in the class. One Sugar volunteer leads the class as the primary teacher.

About 1/2 hour before the class begins, the Sugar volunteers insert the USB sticks and boot each computer. Connections and network neighborhood are checked to see that each boots and they can collaborate.

At the end of class kids are asked to shut down their computers and after they leave the Sugar volunteers collect the sticks.

The class starts with the kids sitting on the carpet. The Sugar teacher projects their screen on a projector and talks about the plan for the class. Typically the kids do an interim step on the computer (e.g. find your computer, start activity n, use it a little) then they go back to the carpet for more direction. Sometimes there are several interim steps and the kids go back and forth from the carpet several times.

==== 3rd Grade Lesson Plans ====
Note: Please confirm if the kids will be in 3rd grade or 4th grade starting in September.

===== Reading and Writing =====

===== Math =====

===== Science =====

===== Social Studies and History =====
''Lesson Plan 1''
* Learn to play and create new games in Memorize
* Create games with pairs of words matching Geography (e.g. country : USA)
* Learn to paint pictures and use them in to Memorize

''Lesson Plan 2''
* Learn to go to Wikipedia, find States, copy images and use them in Memorize
* Open Memorize for collaboration and play with two or more kids

''Lesson Plan 3''
* ?

==Technical Architecture==
* A computer lab with about 20 EVO D500 1.7 GHz Pentium 4, 500 MB RAM computers running Windows 2000
* 20 new Apple laptops in a mobile cart (OSX, hardware details unknown, no Parallels)
* Each teacher has a MacBook with Parallels 3.0
* 100Mb/s LAN
* LAN based collaboration. That is no Jabber or school server, just local (Salut?) collaboration in Network neighborhood.
* Access to Internet (bw?)
* 1 x 1GB USB stick (model?) per kid
* Sugar on a Stick, Strawberry release - http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Strawberry

'''Status for the Computer Lab'''
Boots with the boot-helper CD and connects to the internet if the broadcom drivers are installed.

=== Primary Activities Used ===
* Browse (main target is wikipedia)
* Turtle Art
* Memorize
* Paint (or other drawing program)
* Journal for saving and moving work
* Network Neighborhood for collaborating in real time and sharing work between computers
* Conozco Uruguay
* other?

Note: please add version numbers if anyone has them.

==Critical Path Technical Issues==

* [[http://dev.sugarlabs.org/ticket/75 Ticket 75]]Backup and Restore of user data on a USB Stick - We need to be able to reburn the sticks with new code without losing student work. Also sticks are failing and kids are losing their work.

== How you can help - Technical Tickets ==

The following tickets will help this deployment.

* Memorize with Speak - In progress

* Sugarized Tux Paint

* [[http://dev.sugarlabs.org/ticket/74 Ticket 74]] Clone a Stick. Let a teacher customize a Sugar Stick then clone it, without files or personality, for students to use.

* Can't get Computer Lab Machines to Boot from USB''' - The BIOS says it should be trying to boot from the USB but its not looking at the USB. A google search confirms that this is not a sugar problem, its an EVO D500 problem. I'm hoping we find a solution. http://dev.sugarlabs.org/ticket/599
Google Search on EVO D500 usb boot gives this result: http://forums13.itrc.hp.com/service/forums/bizsupport/questionanswer.do?admit=109447627+1237587827991+28353475&threadId=1038476

* Boot Helper Floppy - This is easier then a CD because the computer has to be turned on to open the CD Drawer and put in the CD then you have to turn it off again and reboot.http://dev.sugarlabs.org/ticket/597

* [[http://dev.sugarlabs.org/ticket/579 Ticket 579]]. We have several donated computers. A requirement for the donations was that we wiped the harddrives. Thus it would be great if we had an installable operating system enabled quick user switching between USBs. This is also impacted by 907, described below.

* [[http://dev.sugarlabs.org/ticket/598 Ticket 598]] and [[http://dev.sugarlabs.org/ticket/907 Ticket 907]] . One way to enable faster switching between Windows and Sugar is a Virtual Machine solution that will allow students to put in their USB Sticks and use all the personal data from the Sticks so they can use any computer. To do this we need to change the way we put data onto the USB and use different partitions for the boot and the data (Ticket 907).

==== Sugar Feature Requests ====
This link records an in process list of priorities for Sugar development with a focus on success at the Gardner Pilot Academy: 
[[Sugar_on_a_Stick/Goals]]
Other feature requests by {{PAGENAME}} are in [[:Category:Features requested by Gardner Pilot Academy]]

It is extracted from this thread on the Sugar Devel List: 
http://lists.sugarlabs.org/archive/sugar-devel/2009-July/016205.html

Please propose additional suggestions on that list. After clarifying and validating the Feature Requests, add them to the Goals page.

Also, on the pages describing features that {{PAGENAME}} request, add <nowiki>[[</nowiki>Category:Features requested by Gardner Pilot Academy]].

[[Category:Project]]

Gardner Pilot Academy

2009-07-20T18:22:01Z

Gregorio: /* 3rd Grade Lesson Plans */

<noinclude>{{GoogleTrans-en}}{{TOCright}}</noinclude>

==Gardner Pilot Academy==
Boston Public Schools - Allston http://www.rabbitnet.net/gpa/

GPA is partnering with Solution Grove and Sugar Labs to pilot [[Sugar on a Stick]].

The Gardner Pilot Academy is the flagship full-service community school within the Boston Public Schools (BPS). The school's vision is to educate the minds and develop the characters of all students in partnership with families and community. To achieve this GPA provides high quality teaching along with a range of social, emotional and enrichment programs delivered by means of partnerships with an array of community organizations and individuals. Over the past twelve years, GPA has developed strong associations with four universities, several health and mental health agencies, the YMCA, and various organizations teaching visual and performing arts. As one of just 20 pilot schools in the BPS, GPA is exempt from district mandates. Therefore, GPA has autonomy in the areas of budget and personnel, along with the freedom to implement innovative curricula, assessments, and interventions.

Located in a culturally and linguistically varied section of Boston, the GPA serves quite a diverse student population. GPA's 336 students and their families speak more than 13 languages ranging from Spanish to Khmer (all of which are supported by Sugar). Demographically, 15.2% are African American, 59.1% are Hispanic, 10.7% are White and 13.1% are Asian. Over 85% of the students meet the federal poverty guidelines for participation in the Free or Reduced Price Lunch Program. The majority of GPA's students fall within a group of students considered to be academically at risk.

GPA is located only a few blocks from Harvard Business School and so is convenient for project development participants who may be students at one of Boston’s many universities.

The school currently has a single computer lab with older computers running Windows 2000. We will be soliciting donations of used equipment from local business to supplement these existing resources. Sugar can be used at all elementary levels and curriculum areas.

==Current computers at GPA==

* A computer lab with about 20 EVO D500 1.7 GHz Pentium 4, 500 MB RAM computers running Windows 2000
* 20 new Apple laptops in a mobile cart (OSX, hardware details unknown, no Parallels)
* Each teacher has a MacBook with Parallels 3.0

There are two teachers in the school especially interested in starting with Sugar:

* 4th Grade teacher who wants to do portfolios
* Science Teacher who wants to pilot with the 5th grade to support a new district mandate for writing in Science

==The Summer Program==

Classes run from July 6 to Aug 17th from 8:30 am to 5pm. The lead teachers over the summer work 10am to 5pm during the school year so we will have good continuity. Here is a [http://www.google.com/calendar/embed?src=t635rhmoabiafhpklue2eoj2lk@group.calendar.google.com&ctz=America/New_York calendar] with GPA events.

They will not be using the mac laptop cart and the summer teachers do not have macbooks.

We will be using the computer lab and we will be talking to the school about putting more computer into classrooms and other locations.

===2nd Grade===

Next Tuesday we will work with the 2nd Graders on their science and social studies. The theme of the week is responsibility and the environment. They will be learning about their community and preping for a cleanup of the local Charles River.

The goal of the first project will be to label a map of where they do the clean up with what they find during their cleanup.

We have half an hour on Tuesday. After kids get their keys and boot up, enter their name and colors we will have them go to Turtle Art. We will prepare maps and preload them on the sticks and show them how to bring them into Turtle Art. Then we'll show them how to have the turtle label them. Next week, after their cleanup they can label what they find on the clean-up.

Maps:
* http://www.paddleboston.com/boston/boston_map.jpg
* http://screencast.com/t/kLcW3O7Tyb4
* http://screencast.com/t/IngjAlCySu

===3rd Grade===

We are hoping that the kids can create a US version of the Uruguay geography/facts game. Any ideas on how to make that easy to do? The vision is they will learn things in class then make them into questions to put into the game. We will meet with the third grade on Thursday afternoons.
===Class notes===
* 15 July - http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg06470.html
* 14 July GS - http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg06412.html
* 14 July AG - http://www.mail-archive.com/iaep@lists.sugarlabs.org/msg05651.html
* 09 July - http://www.mail-archive.com/iaep@lists.sugarlabs.org/msg05561.html
* 08 July - http://www.mail-archive.com/iaep@lists.sugarlabs.org/msg05534.html
* 07 July - http://www.mail-archive.com/iaep@lists.sugarlabs.org/msg05529.html.
* 07 July XS report - http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg06104.html
* 01 July - http://www.mail-archive.com/iaep@lists.sugarlabs.org/msg05416.html

==Looking for Summer Volunteers and Work-Study Students==

We are currently looking for committed volunteers and work-study students for the Summer. We have some funding for Work Study so if you know any eligible students please let us know.

Ideally we would like a team of 3 people, each working around 20 hours per week, consisting of a technical person, a person with education experience and a marketing person.

==Project Goals==

For the GPA School:
* Student Learning,
* Teacher Participation,
* Parent Perception and
* Greater GPA School community perception of the project.

Our goals for the Sugar Project are:
* Sugar on a Stick projects replicated at other schools,
* Improved Sugar for everyone, including OLPC XO children,
* Increased visibility of Sugar, and
* Knowledge and best practices gained for using Sugar in US Schools.

=== More Detailed Sub Goals ===
From our Balanced Score Card: http://spreadsheets.google.com/ccc?key=px5yPvIlUlLtsrYpZdVG_EQ

The Student Learning Section is copied here:
* L1.1 Use of Sugar
* L1.2 Learner Engagement
* L1.3 Extend learning beyond the school day
* L1.4 Students use Sugar to create and explore
* L1.5 Students use Sugar to help create portfolios
* L1.6 Students work collaboratively
* L1.7 Students are proud of their work and feel a sense of ownership
* L1.8 Sugar is supporting learning the curriculum in the classroom
* L1.9 Sugar is supporting exploration and learning outside the curriculum

=== Standard Curriculum ===
Notes on Curriculum from conversation with Assistant principal.

* Fundations for Phonics K-3 - http://www.fundations.com/
* Making Meaning and Being a Writer for 1 - 5 fluency - http://www.devstu.org/being_a_writer/using_mm_with_baw.html
* Investigations for K-5 math - http://investigations.terc.edu/
* Foss program for science - http://www.fossweb.com/

* Massachusetts Curriculum guidelines - http://www.doe.mass.edu/frameworks/current.html

=== Sugar Computer Lab Lesson Plans ===
This section is intended to prepare lesson plans and give details on classroom interactions for the school year starting in September, 2009.

After defining lesson plans here, we can quickly extract SW features and bug fixes which will facilitate this classroom interaction.

==== Context ====
10 - 20 4th grade kids will come to the computer lab once a week for an hour. Each kids gets a USB stick with SoaS and all of their previous work on it. The sticks are kept by the Sugar volunteers and brought back to class each day.

Two teachers and 2 - 4 Sugar volunteers participate in the class. One Sugar volunteer leads the class as the primary teacher.

About 1/2 hour before the class begins, the Sugar volunteers insert the USB sticks and boot each computer. Connections and network neighborhood are checked to see that each boots and they can collaborate.

At the end of class kids are asked to shut down their computers and after they leave the Sugar volunteers collect the sticks.

The class starts with the kids sitting on the carpet. The Sugar teacher projects their screen on a projector and talks about the plan for the class. Typically the kids do an interim step on the computer (e.g. find your computer, start activity n, use it a little) then they go back to the carpet for more direction. Sometimes there are several interim steps and the kids go back and forth from the carpet several times.

==== 3rd Grade Lesson Plans ====
Note: Please confirm if the kids will be in 3rd grade or 4th grade starting in September.

===== Reading and Writing =====

Math

Science

===== Social Studies and History =====
Lesson Plan 1
* Learn to play and create new games in Memorize
* Create games with pairs of words matching Geography (e.g. country : USA)
* Learn to paint pictures and use them in to Memorize

Lesson Plan 2
* Learn to go to Wikipedia, find States and copy images from the site

==Technical Architecture==
* A computer lab with about 20 EVO D500 1.7 GHz Pentium 4, 500 MB RAM computers running Windows 2000
* 20 new Apple laptops in a mobile cart (OSX, hardware details unknown, no Parallels)
* Each teacher has a MacBook with Parallels 3.0
* 100Mb/s LAN
* LAN based collaboration. That is no Jabber or school server, just local (Salut?) collaboration in Network neighborhood.
* Access to Internet (bw?)
* 1 x 1GB USB stick (model?) per kid
* Sugar on a Stick, Strawberry release - http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Strawberry

'''Status for the Computer Lab'''
Boots with the boot-helper CD and connects to the internet if the broadcom drivers are installed.

=== Primary Activities Used ===
* Browse (main target is wikipedia)
* Turtle Art
* Memorize
* Paint (or other drawing program)
* Journal for saving and moving work
* Network Neighborhood for collaborating in real time and sharing work between computers
* Conozco Uruguay
* other?

Note: please add version numbers if anyone has them.

==Critical Path Technical Issues==

* [[http://dev.sugarlabs.org/ticket/75 Ticket 75]]Backup and Restore of user data on a USB Stick - We need to be able to reburn the sticks with new code without losing student work. Also sticks are failing and kids are losing their work.

== How you can help - Technical Tickets ==

The following tickets will help this deployment.

* Memorize with Speak - In progress

* Sugarized Tux Paint

* [[http://dev.sugarlabs.org/ticket/74 Ticket 74]] Clone a Stick. Let a teacher customize a Sugar Stick then clone it, without files or personality, for students to use.

* Can't get Computer Lab Machines to Boot from USB''' - The BIOS says it should be trying to boot from the USB but its not looking at the USB. A google search confirms that this is not a sugar problem, its an EVO D500 problem. I'm hoping we find a solution. http://dev.sugarlabs.org/ticket/599
Google Search on EVO D500 usb boot gives this result: http://forums13.itrc.hp.com/service/forums/bizsupport/questionanswer.do?admit=109447627+1237587827991+28353475&threadId=1038476

* Boot Helper Floppy - This is easier then a CD because the computer has to be turned on to open the CD Drawer and put in the CD then you have to turn it off again and reboot.http://dev.sugarlabs.org/ticket/597

* [[http://dev.sugarlabs.org/ticket/579 Ticket 579]]. We have several donated computers. A requirement for the donations was that we wiped the harddrives. Thus it would be great if we had an installable operating system enabled quick user switching between USBs. This is also impacted by 907, described below.

* [[http://dev.sugarlabs.org/ticket/598 Ticket 598]] and [[http://dev.sugarlabs.org/ticket/907 Ticket 907]] . One way to enable faster switching between Windows and Sugar is a Virtual Machine solution that will allow students to put in their USB Sticks and use all the personal data from the Sticks so they can use any computer. To do this we need to change the way we put data onto the USB and use different partitions for the boot and the data (Ticket 907).

==== Sugar Feature Requests ====
This link records an in process list of priorities for Sugar development with a focus on success at the Gardner Pilot Academy: 
[[Sugar_on_a_Stick/Goals]]
Other feature requests by {{PAGENAME}} are in [[:Category:Features requested by Gardner Pilot Academy]]

It is extracted from this thread on the Sugar Devel List: 
http://lists.sugarlabs.org/archive/sugar-devel/2009-July/016205.html

Please propose additional suggestions on that list. After clarifying and validating the Feature Requests, add them to the Goals page.

Also, on the pages describing features that {{PAGENAME}} request, add <nowiki>[[</nowiki>Category:Features requested by Gardner Pilot Academy]].

[[Category:Project]]

Gardner Pilot Academy

2009-07-20T18:19:55Z

Sugar on a Stick/Goals

2009-07-07T13:56:15Z

Gregorio: /* Backup and Restore with School Server */

Features/Backup and Restore

2009-07-07T13:55:25Z

Gregorio:

<noinclude>{{ GoogleTrans-en | es =show | bg =show | zh-CN =show | zh-TW =show | hr =show | cs =show | da =show | nl =show | fi =show | fr =show | de =show | el =show | hi =show | it =show | ja =show | ko =show | no =show | pl =show | pt =show | ro =show | ru =show | sv =show }}{{TOCright}}</noinclude>





= Feature Name =
''Back Up and Restore''

== Summary ==
Easily back up and restore the Journal of a computer running Sugar (includes SoAS and SoLinux with top priority SoAS). Also, easily back up and restore the full Sugar installation. Beyond the Journal, this includes the activities, any configuration of the OS and the everything needed to restore to its original state.

This feature is a top priority for Gardner Pilot Academy but also requests by essentially every XO deployment.

== Owner ==
* Name: [[User:Gregorio| Greg Smith]]

* Email: gregsmithpm at gmail.com

== Current status ==
* Targeted release: ?
* Last updated: July 7, 2009
* Percentage of completion: ?

== Detailed Description ==
For all the items listed below, implement solution with XS and if possible as a software solution on one or more standard Linux distributions.

''Backup and Restore of the Journal''
* Allow time based backup and restore of the journal. Check for Journal changes on the Sugar computer. Copy any changes to the server on a regular basis. Stagger the copies so that not all Sugar computers backup at the same time. See implementation of this with XO and XS at: http://wiki.laptop.org/go/XS_Blueprints:Datastore_Simple_Backup_and_Restore

* Provide a web based GUI to restore one or all backed up journal entries. The user would boot up any Sugar implementation (user name/password based security is also important) and point their Web browser at a URL on the server. Preferable to automatically take you to the right page (aka the page where your particular Sugar instance is backed up) but would also accept seeing a list of Sugar Journals by user name and picking the right one. Clicking on a single Journal entry or on a link for "full journal" would download those items back in to the journal of the Sugar computer.

* Provide a user initiated backup of the journal. In this case a User would use their web browser to go to a page on the server and click the "backup" link. Then the server would check for changes since the last backup and copy everything from that journal to the server. Same case as above for restore.

* Backup and restor of full sugar instance. Same as above (AKA user initiated and time based server/script) but for the full Sugar instance. This can be only the full instance and does not need to list individual files. For restoring SoAS should support booting up with a USB stick, going to the page, then removing the USB stick and inserting a new one, then clicking restore. This would copy the full Sugar instance to the new USB stick. This would now be a clone of the original USB stick. Also, implement a "clone" feature which allows the same work flow as above but without a server. That is, put a SoAS in a computer, copy it to the computer then restore it to a new USB stick with the full SoAS including configuration.

* Implementing a standard Linux package to do this for Sugar would be fine.

== Benefit to Sugar ==
Ensures that kids and teachers don't lose their work. Backup and restore over the WAN is a major growth technology in commercial SW. e.g. see: http://www.carbonite.com/

A Sugar implementation would be a big feature promotable publicly. Could also be used for a sneaker net type collaboration of last resort. i.e. "get my journal entry off this web page" to move something from one Xo to another.

== Scope ==
Will need client side and server software. May need to move a Linux package to SoAS and may need to push new code upstream to support Journal/Datastore implementation.

== How To Test ==
Create some entries in a journal. Then test with:
* SoAS 8.6 or later and a single computer.
* SoAs 8.6 or later with XS running 0.5 or later.
* SoAS 8.6 or later with Linux distribution
* Test backup and restore of a single journal entry
* Test backup and restore of a full SoAS image. Make sure to use the SoAS so that it changes some files and configurations.
* Test time based backup, preferably with several SoAS computers.

In all cases, ensure that the files are backed up on the server and can be restored on the SoAS. Make sure to open the files in the journal and run them. Also, make sure to cold boot any full images and confirm that changes were saved.

== User Experience ==
Requires a new "web site" on the server for back up and restore.
Requires a configuration option on SoAS to set the time and files to be backed up.

== Dependencies ==
''What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like python?''

Unknown.

== Contingency Plan ==
Plan B is to find a manual way to execute a script which does an "rcp" or other file transfer to a server. Then allows restore via script as well.

== Documentation ==
See XS example above. Will need more documentation.

== Release Notes ==

== Comments and Discussion ==
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] 

==[[Features]] Subpages==
{{Special:PrefixIndex/Features/}}
----
''You can add categories to tie features back to real deployments/schools requesting them, for example <nowiki>[[</nowiki>Category:Feature requested by School Xyz]]''
[[Category:FeaturePageIncomplete]]
[[Category:Feature]]

Features/Backup and Restore

2009-07-07T13:54:49Z

Gregorio:

<noinclude>{{ GoogleTrans-en | es =show | bg =show | zh-CN =show | zh-TW =show | hr =show | cs =show | da =show | nl =show | fi =show | fr =show | de =show | el =show | hi =show | it =show | ja =show | ko =show | no =show | pl =show | pt =show | ro =show | ru =show | sv =show }}{{TOCright}}</noinclude>





= Feature Name =
''Back Up and Restore''

== Summary ==
Easily back up and restore the Journal of a computer running Sugar (includes SoAS and SoLinux with top priority SoAS). Also, easily back up and restore the full Sugar installation. Beyond the Journal, this includes the activities, any configuration of the OS and the everything needed to restore to its original state.

This feature is a top priority for Gardner Pilot Academy but also requests by essentially every XO deployment.

== Owner ==
* Name: [[User:Gregorio| Greg Smith]]

* Email: gregsmithpm at gmail.com

== Current status ==
* Targeted release: ?
* Last updated: July 7, 2009
* Percentage of completion: ?

== Detailed Description ==
For all the items listed below, implement solution with XS and if possible as a software solution on one or more standard Linux distributions.

# Backup and Restore of the Journal
* Allow time based backup and restore of the journal. Check for Journal changes on the Sugar computer. Copy any changes to the server on a regular basis. Stagger the copies so that not all Sugar computers backup at the same time. See implementation of this with XO and XS at: http://wiki.laptop.org/go/XS_Blueprints:Datastore_Simple_Backup_and_Restore

* Provide a web based GUI to restore one or all backed up journal entries. The user would boot up any Sugar implementation (user name/password based security is also important) and point their Web browser at a URL on the server. Preferable to automatically take you to the right page (aka the page where your particular Sugar instance is backed up) but would also accept seeing a list of Sugar Journals by user name and picking the right one. Clicking on a single Journal entry or on a link for "full journal" would download those items back in to the journal of the Sugar computer.

* Provide a user initiated backup of the journal. In this case a User would use their web browser to go to a page on the server and click the "backup" link. Then the server would check for changes since the last backup and copy everything from that journal to the server. Same case as above for restore.

* Backup and restor of full sugar instance. Same as above (AKA user initiated and time based server/script) but for the full Sugar instance. This can be only the full instance and does not need to list individual files. For restoring SoAS should support booting up with a USB stick, going to the page, then removing the USB stick and inserting a new one, then clicking restore. This would copy the full Sugar instance to the new USB stick. This would now be a clone of the original USB stick. Also, implement a "clone" feature which allows the same work flow as above but without a server. That is, put a SoAS in a computer, copy it to the computer then restore it to a new USB stick with the full SoAS including configuration.

* Implementing a standard Linux package to do this for Sugar would be fine.

== Benefit to Sugar ==
Ensures that kids and teachers don't lose their work. Backup and restore over the WAN is a major growth technology in commercial SW. e.g. see: http://www.carbonite.com/

A Sugar implementation would be a big feature promotable publicly. Could also be used for a sneaker net type collaboration of last resort. i.e. "get my journal entry off this web page" to move something from one Xo to another.

== Scope ==
Will need client side and server software. May need to move a Linux package to SoAS and may need to push new code upstream to support Journal/Datastore implementation.

== How To Test ==
Create some entries in a journal. Then test with:
* SoAS 8.6 or later and a single computer.
* SoAs 8.6 or later with XS running 0.5 or later.
* SoAS 8.6 or later with Linux distribution
* Test backup and restore of a single journal entry
* Test backup and restore of a full SoAS image. Make sure to use the SoAS so that it changes some files and configurations.
* Test time based backup, preferably with several SoAS computers.

In all cases, ensure that the files are backed up on the server and can be restored on the SoAS. Make sure to open the files in the journal and run them. Also, make sure to cold boot any full images and confirm that changes were saved.

== User Experience ==
Requires a new "web site" on the server for back up and restore.
Requires a configuration option on SoAS to set the time and files to be backed up.

== Dependencies ==
''What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like python?''

Unknown.

== Contingency Plan ==
Plan B is to find a manual way to execute a script which does an "rcp" or other file transfer to a server. Then allows restore via script as well.

== Documentation ==
See XS example above. Will need more documentation.

== Release Notes ==

== Comments and Discussion ==
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] 

==[[Features]] Subpages==
{{Special:PrefixIndex/Features/}}
----
''You can add categories to tie features back to real deployments/schools requesting them, for example <nowiki>[[</nowiki>Category:Feature requested by School Xyz]]''
[[Category:FeaturePageIncomplete]]
[[Category:Feature]]

Features/Backup and Restore

2009-07-07T13:53:28Z

Gregorio: Created page with '<noinclude>{{ GoogleTrans-en | es =show | bg =show | zh-CN =show | zh-TW =show | hr =show | cs =show | da =show | nl =show | fi =show | fr =show | de =show | el =show | hi =show …'

<noinclude>{{ GoogleTrans-en | es =show | bg =show | zh-CN =show | zh-TW =show | hr =show | cs =show | da =show | nl =show | fi =show | fr =show | de =show | el =show | hi =show | it =show | ja =show | ko =show | no =show | pl =show | pt =show | ro =show | ru =show | sv =show }}{{TOCright}}</noinclude>





= Feature Name =
''Back Up and Restore''

== Summary ==
Easily back up and restore the Journal of a computer running Sugar (includes SoAS and SoLinux with top priority SoAS). Also, easily back up and restore the full Sugar installation. Beyond the Journal, this includes the activities, any configuration of the OS and the everything needed to restore to its original state.

== Owner ==
* Name: [[User:Gregorio| Greg Smith]]

* Email: gregsmithpm at gmail.com

== Current status ==
* Targeted release: ?
* Last updated: July 7, 2009
* Percentage of completion: ?

== Detailed Description ==
For all the items listed below, implement solution with XS and if possible as a software solution on one or more standard Linux distributions.

# Backup and Restore of the Journal
* Allow time based backup and restore of the journal. Check for Journal changes on the Sugar computer. Copy any changes to the server on a regular basis. Stagger the copies so that not all Sugar computers backup at the same time. See implementation of this with XO and XS at: http://wiki.laptop.org/go/XS_Blueprints:Datastore_Simple_Backup_and_Restore

* Provide a web based GUI to restore one or all backed up journal entries. The user would boot up any Sugar implementation (user name/password based security is also important) and point their Web browser at a URL on the server. Preferable to automatically take you to the right page (aka the page where your particular Sugar instance is backed up) but would also accept seeing a list of Sugar Journals by user name and picking the right one. Clicking on a single Journal entry or on a link for "full journal" would download those items back in to the journal of the Sugar computer.

* Provide a user initiated backup of the journal. In this case a User would use their web browser to go to a page on the server and click the "backup" link. Then the server would check for changes since the last backup and copy everything from that journal to the server. Same case as above for restore.

* Backup and restor of full sugar instance. Same as above (AKA user initiated and time based server/script) but for the full Sugar instance. This can be only the full instance and does not need to list individual files. For restoring SoAS should support booting up with a USB stick, going to the page, then removing the USB stick and inserting a new one, then clicking restore. This would copy the full Sugar instance to the new USB stick. This would now be a clone of the original USB stick. Also, implement a "clone" feature which allows the same work flow as above but without a server. That is, put a SoAS in a computer, copy it to the computer then restore it to a new USB stick with the full SoAS including configuration.

* Implementing a standard Linux package to do this for Sugar would be fine.

== Benefit to Sugar ==
Ensures that kids and teachers don't lose their work. Backup and restore over the WAN is a major growth technology in commercial SW. e.g. see: http://www.carbonite.com/

A Sugar implementation would be a big feature promotable publicly. Could also be used for a sneaker net type collaboration of last resort. i.e. "get my journal entry off this web page" to move something from one Xo to another.

== Scope ==
Will need client side and server software. May need to move a Linux package to SoAS and may need to push new code upstream to support Journal/Datastore implementation.

== How To Test ==
Create some entries in a journal. Then test with:
* SoAS 8.6 or later and a single computer.
* SoAs 8.6 or later with XS running 0.5 or later.
* SoAS 8.6 or later with Linux distribution
* Test backup and restore of a single journal entry
* Test backup and restore of a full SoAS image. Make sure to use the SoAS so that it changes some files and configurations.
* Test time based backup, preferably with several SoAS computers.

In all cases, ensure that the files are backed up on the server and can be restored on the SoAS. Make sure to open the files in the journal and run them. Also, make sure to cold boot any full images and confirm that changes were saved.

== User Experience ==
Requires a new "web site" on the server for back up and restore.
Requires a configuration option on SoAS to set the time and files to be backed up.

== Dependencies ==
''What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like python?''

Unknown.

== Contingency Plan ==
Plan B is to find a manual way to execute a script which does an "rcp" or other file transfer to a server. Then allows restore via script as well.

== Documentation ==
See XS example above. Will need more documentation.

== Release Notes ==

== Comments and Discussion ==
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] 

==[[Features]] Subpages==
{{Special:PrefixIndex/Features/}}
----
''You can add categories to tie features back to real deployments/schools requesting them, for example <nowiki>[[</nowiki>Category:Feature requested by School Xyz]]''
[[Category:FeaturePageIncomplete]]
[[Category:Feature]]

User:Gregorio

2009-07-07T13:13:49Z

Gregorio:

<noinclude>{{ GoogleTrans-en | es =show | bg =show | zh-CN =show | zh-TW =show | hr =show | cs =show | da =show | nl =show | fi =show | fr =show | de =show | el =show | hi =show | it =show | ja =show | ko =show | no =show | pl =show | pt =show | ro =show | ru =show | sv =show }}{{TOCright}}</noinclude>

[[Features/Back Up and Restore]]

'''Comments and Explanations:'''

There are comments (in italic) providing guidance to fill out each section. '''Copy the source to a ''new page'' before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR FEATURE.'''





= Feature Name =
''The name of your feature''

== Summary ==
''A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release.''

== Owner ==
''This should link to your home wiki page so we know who you are''
* Name: [[User:AcountName| Your Name]]

''Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved''
* Email: <your email address so we can contact you, invite you to meetings, etc.>

== Current status ==
* Targeted release: (SUGAR_VERSION)
* Last updated: (DATE)
* Percentage of completion: XX%

== Detailed Description ==
''Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better.''

== Benefit to Sugar ==
''What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Sugar become a better platform or project because of this feature?''

== Scope ==
''What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?''

== How To Test ==
''This does not need to be a full-fledged document. Describe the dimensions of tests that this feature is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be.''

''Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.''

''A good "how to test" should answer these four questions:''

* ''What special hardware / data / etc. is needed (if any)?
* ''How do I prepare my system to test this feature? What packages need to be installed, config files edited, etc.?
* ''What specific actions do I perform to check that the feature is working like it's supposed to?
* ''What are the expected results of those actions?''

== User Experience ==
''If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice.''

== Dependencies ==
''What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like python?''

== Contingency Plan ==
''If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "None necessary, revert to previous release behaviour." Or it might not. If you feature is not completed in time we want to assure others that other parts of Sugar will not be in jeopardy.''

== Documentation ==
''Is there upstream documentation on this feature, or notes you have written yourself? Link to that material here so other interested developers can get involved.''

== Release Notes ==
''The Sugar Release Notes inform end-users about what is new in the release. An Example is [[0.84/Notes]]. The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the release team and shipped with the release.''

== Comments and Discussion ==
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] 

==[[Features]] Subpages==
{{Special:PrefixIndex/Features/}}
----
''You can add categories to tie features back to real deployments/schools requesting them, for example <nowiki>[[</nowiki>Category:Feature requested by School Xyz]]''
[[Category:FeaturePageIncomplete]]
[[Category:Feature]]

User:Gregorio

2009-07-07T13:10:48Z

<noinclude>{{ GoogleTrans-en | es =show | bg =show | zh-CN =show | zh-TW =show | hr =show | cs =show | da =show | nl =show | fi =show | fr =show | de =show | el =show | hi =show | it =show | ja =show | ko =show | no =show | pl =show | pt =show | ro =show | ru =show | sv =show }}{{TOCright}}</noinclude>

'''Comments and Explanations:'''

There are comments (in italic) providing guidance to fill out each section. '''Copy the source to a ''new page'' before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR FEATURE.'''





= Feature Name =
''The name of your feature''

== Summary ==
''A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release.''

== Owner ==
''This should link to your home wiki page so we know who you are''
* Name: [[User:AcountName| Your Name]]

''Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved''
* Email: <your email address so we can contact you, invite you to meetings, etc.>

== Current status ==
* Targeted release: (SUGAR_VERSION)
* Last updated: (DATE)
* Percentage of completion: XX%

== Detailed Description ==
''Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better.''

== Benefit to Sugar ==
''What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Sugar become a better platform or project because of this feature?''

== Scope ==
''What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?''

== How To Test ==
''This does not need to be a full-fledged document. Describe the dimensions of tests that this feature is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be.''

''Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.''

''A good "how to test" should answer these four questions:''

* ''What special hardware / data / etc. is needed (if any)?
* ''How do I prepare my system to test this feature? What packages need to be installed, config files edited, etc.?
* ''What specific actions do I perform to check that the feature is working like it's supposed to?
* ''What are the expected results of those actions?''

== User Experience ==
''If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice.''

== Dependencies ==
''What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like python?''

== Contingency Plan ==
''If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "None necessary, revert to previous release behaviour." Or it might not. If you feature is not completed in time we want to assure others that other parts of Sugar will not be in jeopardy.''

== Documentation ==
''Is there upstream documentation on this feature, or notes you have written yourself? Link to that material here so other interested developers can get involved.''

== Release Notes ==
''The Sugar Release Notes inform end-users about what is new in the release. An Example is [[0.84/Notes]]. The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the release team and shipped with the release.''

== Comments and Discussion ==
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] 

==[[Features]] Subpages==
{{Special:PrefixIndex/Features/}}
----
''You can add categories to tie features back to real deployments/schools requesting them, for example <nowiki>[[</nowiki>Category:Feature requested by School Xyz]]''
[[Category:FeaturePageIncomplete]]
[[Category:Feature]]