Difference between revisions of "Google Code-In 2012/GCI2012 Brainstorming"
| Line 12: | Line 12: | ||
;User Interface: Tasks related to user experience research or user interface design and interaction | ;User Interface: Tasks related to user experience research or user interface design and interaction | ||
| − | |||
1) Activity Rescue. | 1) Activity Rescue. | ||
| − | There are abandoned | + | There are abandoned activities that need to be ported to gtk3 or generally resuscitated. For example, some have been left behind on [dev.laptop.org] and not migrated to Sugar Labs hosting. |
2) Activity internationalization. | 2) Activity internationalization. | ||
| − | There are a number of activities in ASLO that are either English only or Spanish only. Each one could of these could be listed as an individual task to refactor for i18n and submit for Pootle hosting. See [[File:ASLO_spreadheet_Oct_2012.ods]] | + | There are a number of activities in [activities.sugarlabs.org ASLO] that are either English only or Spanish only. Each one could of these could be listed as an individual task to refactor for i18n and submit for Pootle hosting. See [[File:ASLO_spreadheet_Oct_2012.ods]] |
| Line 32: | Line 31: | ||
| + | 4) Infrastructure tasks | ||
| + | |||
| + | For example, I'll be creating a task for a new pootle-helper script to do msgfmt checks on PO files as part fo our regular Pootle cron jobs to prevent build-breakers in PO files from going unnoticed for more than 24 hours. | ||
| + | |||
| + | 5) GTK-3 conversion | ||
| + | |||
| + | We have migrated Sugar to GTK-3 and introspection, but many activities still use the old GTK-2 framework. Migrating these activities would help to stabilize our code base and make ling-term maintenance more tractable. | ||
| − | |||
| − | + | [[Category: GCI2012]] | |
Revision as of 07:47, 26 October 2012
These are genereal concepts and areas of opportunity from which individual GCI2012 tasks can be developed and submitted. We need at least 5 tasks in each category, but beyond tha we can have as many as we can think up.
The GCI categories are:
- Code
- Tasks related to writing or refactoring code
- Documentation/Training
- Tasks related to creating/editing documents and helping others learn more
- Outreach/Research
- Tasks related to community management, outreach/marketing, or studying problems and recommending solutions
- Quality Assurance
- Tasks related to testing and ensuring code is of high quality.
- User Interface
- Tasks related to user experience research or user interface design and interaction
1) Activity Rescue.
There are abandoned activities that need to be ported to gtk3 or generally resuscitated. For example, some have been left behind on [dev.laptop.org] and not migrated to Sugar Labs hosting.
2) Activity internationalization.
There are a number of activities in [activities.sugarlabs.org ASLO] that are either English only or Spanish only. Each one could of these could be listed as an individual task to refactor for i18n and submit for Pootle hosting. See File:ASLO spreadheet Oct 2012.ods
3) Sugarizing good Python (or other) programs.
There are nice packages out there that could be readily ported to run as Sugar Activities by various means. Identifying a number of candidate packages to be sugarized as a GCI task would enhance the Sugar user experience in ways we have not had adequate time to do.
For example, it would be wonderful to empower "bootstrapping" of L10n on the XO from within Sugar itself by porting a version Virtaal as a Sugar Activity capable of reading and writing the PO/MO files already present in the source code (if coupled with glibc locale availability),
4) Infrastructure tasks
For example, I'll be creating a task for a new pootle-helper script to do msgfmt checks on PO files as part fo our regular Pootle cron jobs to prevent build-breakers in PO files from going unnoticed for more than 24 hours.
5) GTK-3 conversion
We have migrated Sugar to GTK-3 and introspection, but many activities still use the old GTK-2 framework. Migrating these activities would help to stabilize our code base and make ling-term maintenance more tractable.