Google Code-In 2012

From Sugar Labs
Revision as of 11:26, 3 November 2012 by Walter (talk | contribs) (→‎TASKS)
Jump to navigation Jump to search

Sugar Labs is applying to Google Code-in for 2012.

Why we are applying

Sugar is written and maintained by volunteers, who range from seasoned professionals to children as young as 12-years of age. Children who have grown up with Sugar have transitioned from Sugar users to Sugar App developers to Sugar maintainers. They hang out on IRC with the global Sugar developer community and are full-fledged members of the Sugar development team. It is this latter group of children we hope will participate in and benefit from Google Code-in. Specifically we want to re-enforce the message that Sugar belongs to its users and that they have both ownership and the responsibility that ownership implies. Just as learning is not something done to you, but something you do, learning with Sugar ultimately means participating in the Sugar development process. At Sugar Labs, we are trying to bring the culture of Free Software into the culture of school. So the Code-in is not just an opportunity for us to get some tasks accomplished, it is quintessential to our overall mission.

About GCI

Code-in FAQ

TASKS

Please be sure to include at least 5 tasks from each of the 5 categories.

This brainstorming page lists some general categories from which specific individual tasks can be specified. (Note: We had a number of tasks listed in our GSOC application that may be relevant to GCI.)

Code
Tasks related to writing or refactoring code
  1. Write a new pootle-helper script for doing preventative msgfmt checks.
  2. Sugarize Virtaal for L10n "bootstrapping".
  3. Convert Sugar activities from GTK-2 to GTK-3 framework.
  4. Enable touch for activities that use direct keyboard input.
  5. Package Sugar activity utilities (e.g., [1]) for inclusion in the Sugar toolkit.
Documentation/Training
Tasks related to creating/editing documents and helping others learn more
  1. Write a Turtle Art introductory tutorial.
  2. Identify and document a generalized (ideally automated) method for taking nearly identical screen shots with the desktop set to a selected list of different languages. (Possibly Orca?).
  3. Flesh out the GTK-2 to GTK-3 conversion documentation to include more comprehensive coverage of Pango.
  4. Better document the process of creating and using Sugar on a Stick, the LiveUSB version of Sugar.
  5. Better document the process of running Sugar in a virtual machine (VM).
  6. Create videos on how to use Sugar and how to use core Sugar activities.
Outreach/Research
Tasks related to community management, outreach/marketing, or studying problems and recommending solutions
  1. Research internationalization of SVG images.
  2. Research what metadata about Sugar activity usage would be helpful to teachers for assessment purposes.
  3. Research what opportunities/roadblocks exist for running Sugar in your local schools.
  4. Research the issues involved with porting Suagr to "the Cloud".
  5. Research the issues involved with porting Sugar to Android.
Quality Assurance
Tasks related to testing and ensuring code is of high quality.
  1. Do an analysis of which Sugar activities are are orphaned.
  2. Do an analysis of which Sugar activities are touch-enabled or need modifications to support touch.
  3. Do an analysis of which Sugar activities are lacking in documentation (e.g., Activity wiki page).
  4. Do an analysis of which Sugar activities are have issues running on non-x86 architectures (e.g. ARM).
  5. Do an analysis of which Sugar activities are lacking i18n support.
User Interface
Tasks related to user experience research or user interface design and interaction
  1. Help us design the Sugar affordances for Sugar on tablet computers (Sugar Touch).
  2. Develop new Maliit keyboard files for additional languages(beyond those already developed by garycmartin).
  3. Think of ways to further leverage the use of an accelerometer in Sugar (and other common sensors found in portable computing devices).
  4. Assessing how Sugar is used by students. What is learnt? Survey students and teachers. How well does it deliver its goals?
  5. Survey Sugar users to find out what UI features they want from Sugar in the future.