2,354
edits
Changes
Jump to navigation
Jump to search
Line 1:
Line 1: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 10:
Line 41: − + Line 101:
Line 132: − + Line 108:
Line 139: + + + + + + + + + + Line 119:
Line 160: − + − * 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). Line 151:
Line 184: − # 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.+
Oversight Board/2011/Meeting Minutes-2011-09-16 (view source)
Revision as of 23:07, 16 September 2011
, 23:07, 16 September 2011→Team Reports
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===
===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]
* [http://lists.sugarlabs.org/archive/iaep/2011-September/014077.html Activity]
* [http://lists.sugarlabs.org/archive/iaep/2011-September/014045.html Infrastructure]
* [http://lists.sugarlabs.org/archive/iaep/2011-September/014045.html Infrastructure]
* [http://lists.sugarlabs.org/archive/iaep/2011-September/014066.html Marketing]
* [http://lists.sugarlabs.org/archive/iaep/2011-September/014066.html Marketing]
* [http://lists.sugarlabs.org/archive/iaep/2011-September/014027.html Platform]
* [[Platform_Team/Roadmap|Platform]]
* [http://lists.sugarlabs.org/archive/iaep/2011-September/014046.html Translation]
* [http://lists.sugarlabs.org/archive/iaep/2011-September/014046.html Translation]
* [[Wiki_Team/Roadmap|Wiki]]
* [[Wiki_Team/Roadmap|Wiki]]
===Constraints===
===Constraints===
====What does the team see as its constraints from being more successful in its Mission?====
====What does the team see as its constraints from being more successful in its mission?====
''Activity''
''Activity''
* Finding developers willing to maintain activity code over the longer term.
* Finding developers willing to maintain activity code over the longer term.
''Education''
''Education''
* Lack of a forum for teachers: IRC and the wiki are not places where teachers naturally congregate.
* 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''
''Wiki''
* Participation
* Participation
* Mining mail lists, wikis, blogs, for any thing that might be appropriate.
* Mining mail lists, wikis, blogs, for any thing that might be appropriate.
''Marketing''
''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.
* 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''
''Translation''
* Recruitment of additional localizers.
* Recruitment of additional localizers.
*# 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?
*# 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''
''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''
''Wiki''
* Promote greater documentation and interlinking of information.
* Promote greater documentation and interlinking of information.
* Attract more participants by public discussion.
* Attract more participants by public discussion.