View source for Oversight Board/2011/Meeting Minutes-2011-09-16

In attendance:

SLOB members: walter, cjb, icarto, alsroot, bernie

Community members including: cjl, JT4sugar, wernerio, SeanDaly, garycmartin, raffael

== Agenda ==

# Team Reports
# Local Lab Reports
# Resources discussion

----

'''MOTION''' Keep the GSoC 2010 mentor funds as our general funds, as previously decided, revisiting the decision of whether to give some/all of them to the mentors themselves next time we do a SoC.

Motion passed 4 yes; 1 not voting; 2 not present

----

===Action items===

# follow up meeting to look at content support (including activity output and commentary)
# follow up meeting re content for the new website
# follow up meeting re deployment team <--> local labs
# bernie to put our financial house in order
# walter to report motion to SFC


===Team Reports===

[[File:Sugar team and local labs updates sept 2011 som.jpg|thumb|380px|Self-Organizing Map from team and local lab report text.]]

* [http://lists.sugarlabs.org/archive/iaep/2011-September/014077.html Activity]
* Bug Squad
* Deployment
* [http://lists.sugarlabs.org/archive/iaep/2011-September/014080.html Design]
* Development
* [http://lists.sugarlabs.org/archive/iaep/2011-September/014011.html Documentation]
* [http://lists.sugarlabs.org/archive/iaep/2011-September/014043.html Education]
* [http://lists.sugarlabs.org/archive/iaep/2011-September/014045.html Infrastructure]
* [http://lists.sugarlabs.org/archive/iaep/2011-September/014066.html Marketing]
* [[Platform_Team/Roadmap|Platform]]
* [http://lists.sugarlabs.org/archive/iaep/2011-September/014046.html Translation]
* [[Wiki_Team/Roadmap|Wiki]]

===Local Labs===

* [http://lists.sugarlabs.org/archive/iaep/2011-September/014035.html Germany]
* [http://lists.sugarlabs.org/archive/iaep/2011-September/014034.html Peru]
* [http://lists.sugarlabs.org/archive/iaep/2011-September/014059.html Chile]

===Goals===

====Short-term goals====
''Activity''
* Finish implementation of the UI review with guidance of the Design Team.
* Write a criteria for inclusion of activities into the core activities group.
* Create a list of core activities, with the maintainers responsible for each one of them.
* Re-start Activity Team IRC meetings.
* Look to the Development Team for a best practice recommendation for GTK3, PyGI activity migration and Sugar 0.96 red flag day changes.
''Design''
* Write updated Sugar HIG.
* Work with Activity Team to finish implementation of the ongoing Activity UI review.
* Improve Home view Start new/Resume work flow.
* Improve Group view.
* Improve touch based UI support.
''Education''
* Finish writing up the report and recommendations from the [http://wiki.laptop.org/go/Innovation_in_Evaluation Innovation in Evaluation meeting] held in April, 2011
* Finish writing an essay on Fundamental Ideas on Learning
''Infrastructure''
* Raise the [bar] for adding new services: any new machine and web application must have one clear owner who accepts to be fully accountable for its maintenance.
''Marketing''
* Launch new website, with new content in particular screencasts
ready for localization.
* Define new strategy.
* Ramp up social media participation.
''Translation''
* High level of coverage of Glucose and Fructose projects for Sugar 0.94 release.
* High level of coverage in selected langauges taregeted for OLPC 11.3.0 release
* Improvements in i18n / L10n workflow through maintenance and enhancement of Pootle server infrastructure (i.e Pootle version upgrade) and it's interactions with version control systems (i.e. Gitorious).
''Wiki''
* Monitor OpenQwaq service development for potential collaboration with wiki services.
* Monitor [[mediawikiwiki:Extension:WikiEditor]] for sufficient maturation for our use.
* Monitor [[Marketing_Team/Website |www.sugarlabs.org website plans]] for integration with this wiki.

====Medium-term goals====

''Activity''
* Promote co-maintainership of Core Activities.
* Identify code repeated in activities, and useful in sugar-toolkit, and help to improve it, doing easier the work to activity developers.
* Try to gather more feedback on actual activity use by children in deployments to help focus development effort (Journal metadata analysis, teacher feedback, deployment team feedback).
* Look to the Design Team to help work towards adoption of UI changes needed for the support of touch based interfaces.
''Design''
* Work on Sugar UI design changes for improved support on touch only based interfaces (e.g. virtual keyboard support).
* Revisit original Sugar design goals and see if any are able move forward (overlay chat, bulletin board, Journal object vs action view, Journal versioning UI, etc).
''Education''
* Design a portal for content sharing among teachers and Sugar users, i.e., a space for people to share objects, artifacts, and reflections
* Design a space for building connections between local curricula guidelines and Sugar activities
''Marketing''
* Build up the Marketing Team.
* Develop and launch merchandising.
* Improve trademarks protection.
''Platform Team''
* Support ''doing'' behaviors by providing useful [[Platform_Team/Sweets|distribution method]]s and various Sugar Doers' Kits.
* Connect doers and other learners (users) by developing services for a seamless infrastructure for sharing software, e.g., [[Activity Library]].
* Extend the previous two goals to non-Sugar environments, not to ''sugarize'' them all, but rather to merge and promote Sugar software with and within the common [http://en.wikipedia.org/wiki/Free_software Free Software] and education ecosystems.
''Translation''
* Increase administrative efficiency and task automation (e.g. Pootle-git interactions).
* Chris Leonard has started cross-training on infrastructure-facing tasks, but both Chris Leonard and Rafael Ortiz should recruit and train backups / replacements for both community-facing and infrastructure-facing tasks.  The infrastructure-facing tasks require elevated privs and so this must be a joint recruitment with the Infrastructure Team of a trusted individual.
* Maintain and enhance level of cross-talk between Translation Team and Release Teams (string freeze announcements, etc.).
''Wiki''
* Investigate inter-wiki searching options that would allow for joint searching of Sugar Labs and collaborator wikis.
* Seek collaboration on better separation and joining of information between collaborator wikis,'' i.e.'',
** [[Human Interface Guidelines]] and [[olpc:OLPC Human Interface Guidelines|OLPC Human Interface Guidelines]], where versions are diverging.

====Long-term goals====
''Activity''
* Design, develop, or support an activity (or Sugar shell component) useful to edit/create activities.
''Education''
* Digital textbooks incorporating Sugar activities
''Marketing''
* With funding, develop a media mix including advertising to reach teachers.
* With funding, commission recurrent market studies to better understand (a) teacher attitudes to information and communications technology (ICT) in the classroom and Sugar's competitors in particular and (b) market shares of major competitors.
* Work toward OEM deals beyond OLPC including joint marketing.
''Translation''
* Work on providing i18n tools and training to deployments to facilitate the sharing locally developed Sugar-based materials across deployments / languages.
* Continuing outreach to upstreams to enhance overall coverage of the FOSS ecosystem surrounding Sugar / OLPC builds.
* Continuous improvement of existing L10n projects through po-conflict analysis, term standardization, response to feedback from learners and deployments and providing i18n / L10n feedback to developers.
''Wiki''
* Seek more ways to automatically embed integrative links on mailing list posts, patchwork, gitorious, bugs, doc, translate, etc. products so Learners can easily navigate to the '''''source'''''.

===Constraints===
====What does the team see as its constraints from being more successful in its mission?====
''Activity''
* Finding developers willing to maintain activity code over the longer term.
''Design''
* Ability to gather feedback and usage information from our target users to help complete the design loop.
''Education''
* Lack of a forum for teachers: IRC and the wiki are not places where teachers naturally congregate.
''Marketing''
* The chief constraint at this time is lack of resources. Marketing and PR are costly and it is quite difficult to obtain meaningful results without funding. The Marketing Coordinator has personally funded nearly all expenses up to now, but it is no longer possible for me to donate several thousand euros per year (not including travel expenses). In my view we need to find contributors to start and develop a Fundraising Team. Beyond that, the community would need to support earmarking a hefty share of the budget for marketing and PR.
* We do not have a strategy at this time. The previous strategy - combating the installation barrier by marketing a demo version as Sugar on a Stick spotlighting the benefits of Activities, and combating the unfamiliarity barrier by raising awareness working with the press - was successful, but unfortunately fell apart after Sugar on a Stick was taken over by Fedora. We consider teacher buy-in to be essential, yet we are unable to offer a simple path for trying Sugar to teachers. We have laid groundwork for an umbrella "Virtual Sugar" strategy - proposing a matrix (distros, languages, Activity sets) of preconfigured VMs for Windows, OS X, and GNU/Linux, supporting many distros on an egalitarian basis - but this is on hold unless the community can choose to support this approach. A variant involves online emulation of the Sugar experience, but the technical challenges appear to be insurmountable at this time.
* Technical orientation of Sugar Labs. This is a difficult and possibly insurmountable structural problem. The majority of SL contributors today have an engineering background; the hacker-teacher disconnect has been well documented. There is widespread ignorance, dismissal, or distrust of the importance of marketing, PR, and trademarks. Often, the professionalism in writing, reviewing, and committing code disappears when it comes time to do marketing or PR where anything goes (cf. obscure project names). There is an over-reliance on systems and technical tools. Contributing code is a higher-status activity than doing something else, which encourages a caste system. In these regards Sugar Labs closely resembles other free/libre open source software technical projects. Unfortunately, very few such projects have ever succeeded breakout marketing. I believe we need to break the mold and do things differently.
* Product quality. Sugar is buggy and, if not already installed on a non-OLPC computer, represents a technical challenge for teachers who need a trouble-free tool in the classroom. A reliable, bulletproof Sugar would spread very quickly by word of mouth; teachers would become product evangelists. This is not possible today. Compounding the problem, teachers do not find the assistance and support they need on our current websites; the MIT MarketLab study showed that today, our site is not fulfilling its role of informing and supporting teachers. We may want to consider a one-year development cycle over the existing six-month cycle in order to focus on quality.
* Absence of OLPC marketing support. OLPC has never had a marketing department, yet has done a great job of raising awareness through world-class PR and product design. To my knowledge, OLPC has never conducted a market study concerning teacher awareness, but anecdotal evidence suggests that aided awareness of "the little green laptop with a crank" is quite high. Unfortunately, Sugar is often omitted in OLPC communications; for example OLPC's new website's About/Software page only mentions Sugar in passing, with no logo at all. The OLPC Association has helpfully worked on promoting Sugar as part of their value proposition in pitches, but consistent joint marketing with OLPC would benefit everyone in the ecosystem.
* Limited availability of XOs. From the start of the project until today, with the exception of the G1G1 program, it is extremely difficult for teachers and journalists to obtain an XO laptop running Sugar. As this is Sugar's native platform - eliminating the installation barrier - this policy hampers our ability to easily demonstrate Sugar as it used by most Learners today. Adam has done a great job with the Contributors Program, but the possibility of easily organizing small deployments would be invaluable for obtaining feedback.
* Absence of usage experience data from teachers and Sugar Learners. With over two million instances of Sugar in use through OLPC, we do not have consistent, reliable feedback flowing back to us from the major deployments. We are not even sure which versions of Sugar are in use where. This information is vital for us to understand teachers' and pupils' needs better and to shape our marketing message.
* Documentation. Sugar is an unfamiliar interface for teachers and documentation (including screencasts) need to be improved. (I have struggled for two years to find a reliable screencast solution, I am hoping the newly updated Activity will fit the bill.) Rich documentation eases the preparation of marketing materials.
* Infrastructure. With Google Apps, we were able to easily publish our PR. This has disappeared and there is as yet no replacement (I use gmail and mass mailings are immediately blocked from personal accounts).
''Wiki''
* Participation
* Technological complexity
* Complexity of organizing information

====What are we doing to try to resolve the constraint?====
''Activity''
* We will restart periodic IRC meetings (probably once a fortnight) to try and re-engage activity developers.
''Design''
* Mining mail lists, wikis, blogs, for any thing that might be appropriate.
''Marketing''
* The marketing challenges can be met. I am however pessimistic concerning the technical orientation of the project. In my view, if teachers had more weight in Sugar Labs, the Marketing Team could spend a lot less time explaining and fighting and more time marketing. However, for this to happen, developers would need to accept teachers' recommendations concerning the project's orientations. FLOSS engineers generally have a healthy aversion to accepting assigned projects such as at classic marketing-run companies like Microsoft or Apple. It is my hope that SL developers (and packagers, etc.) would become motivated to do so through contact with teachers and Learners and reliable feedback concerning Sugar.
''Translation''
* Recruitment of additional localizers.
* Raising awareness within the activity and content developer
community of the importance of i18n.
* Tools for long-form content L10n are still inadequate and
continuing evaluation is needed.
''Wiki''
* Maintain quality of information and service.
* Watch for prime wiki applications where thresholds are low and ceilings high.

====What can Sugar Labs 'central' or the community do to help?====
''Activity''
* Get involved in some way with Activity testing, review, feedback, opening bug or enhancement tickets, documentation, lesson plan writing, video tutorials – so that activity developers are not working in a vacuum. More feedback from the bottom up would be wonderful (children/teacher/deployment -> activity developers)
''Design''
* Provide more feedback about how Sugar is being used by our target users so we can refine, or replace design elements.
''Education''
* Help us find the place(s) where teachers would be willing to engage.
''Marketing''
* I believe it is critical for Sugar Labs to:
*# Raise funds. The absence of resources causes many other unnecessary difficulties. This of course also involves a treasurer and comptroller, but countless other nonprofits have met that challenge.
*# Create a forum for teachers. This was a key recommendation of the MarketLab study and is underway for the new SL website. This could help us in gathering reliable feedback from deployments. We will need moderators!
*# Give more governance weight to educators. This could be achieved in several ways, but I believe the best way would be to form an executive committee of team leaders meeting periodically. The marketing strategy could be aligned with the development roadmap for a start, resources allocation could be hashed out, in general more unity of purpose could be achieved. At the same time, I believe it may be beneficial to remake the Oversight Board with allocated seats for educators (under the current conditions they will never be elected). Perhaps candidates could run as either general contributor or educator, and the top two scoring educators could take seats on the Board?
''Translation''
* Increase L10n recruitment activities through personal or collaborative contacts.  This is something to which every Sugar Labs member should contribute, but the Deployment Team (especially OLPC deployment partners) and the Local Labs have particular responsibilities for their native languages.
* Infrastructure Team support required for Pootle upgrade.
* Activity Team collaboration required to increase i18n of ASLO activities.
* Bug Squad could enhance testing of LTR and bidirectional language support.  Arabic / Dari or Hebrew testers would be especially useful.
* Design Team should keep i18n / L10n issues in mind when making choices, e.g. bolding of text is not ideal for i18n / L10n (depending on the fonts available), whereas color highlighting is language neutral.
* There are happily a wealth of materials being developed in local languages by local deployments, unhappily very few of those materials are being upstreamed by re-basing on the most-common English i18n formats.  The Education Team and Local Labs should take the lead in identifying suitable materials and advocating for i18n into a format that will work with our existing infrastructure and resources (i.e. English msgids).
* The previous point is not anglocentrism, but rather an acknowledgment of the reality that we have a primarily lang-en to lang-XX L10n community.  A similar acknowledgment of linguistic reality has caused us to develop materials and methods to facilitate re-basing on Spanish for L10n into indigenous languages.  This places a particular urgency on keeping lang-es L10n current at all times to allow lang-es strings to be used as a bridge to indigenous languages.
''Wiki''
* Promote greater documentation and interlinking of information.
* Attract more participants by public discussion.