Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
On Wed, Sep 23, 2009 at 08:06:43AM -0500, David Farning wrote: This sets several important [precedents]: Delegate authority - In this case the soas project can define its own future. And the marketing team can define its own marketing strategy. This is not the precedent. Authority has not been delegated. SLOBs is still making the decision: 'The Oversight Board will review and ratify Decision Panel [report]' http://lists.sugarlabs.org/archive/sugar-devel/2009-September/019544.html The decision panel is going to be told what the question(s) it has to report on is...so let's not pat ourselves on the back on being decisive here. Sugar Labs does not declare an official soas. Instead, the marketing team can pick the best soas on which to base its strategy. Is this your personal opinion or SLOB's? It seems broadly phrased if the former, contradictory if the latter. [T]he meta [lessons] from this experience:) 1. [Trademark guidelines are overdue] 2. [project policy is overdue] 3. [soas and marketing teams can work together] All I see is a lot of unproductive reinforcement of 4. let's talk a lot about tangential stuff to the detriment of letting SLOBs get on with answering the original question[1,2]. Like I said: It's not hard to say 'no', but it takes a 150 post mailing list thread and a committee to really avoid saying it for so long and with such obfuscation. david Martin 1. http://lists.sugarlabs.org/archive/iaep/2009-September/008373.html 2. http://lists.sugarlabs.org/archive/iaep/2009-September/008473.html 3. http://lists.sugarlabs.org/archive/iaep/2009-September/008469.html pgp4yY8ZCmur3.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
All I see is a lot of unproductive reinforcement of 4. let's talk a lot about tangential stuff to the detriment of letting SLOBs get on with answering the original question[1,2]. Patches welcome. Process and product are both important; the former builds our capacity to get on with making the latter. Think of those sections of this thread as a review request for a decisionmaking protocol. Rather than generalizing I don't need this to nobody needs this, step back and think about why *somebody* (in this case, multiple somebodies) thought we needed something like it. What are they trying to accomplish? I highly doubt anyone here has the goal of talking a lot about tangential stuff - we're all trying to get our own stuff done too, and for whatever reason, some folks feel blocked and are (or were) trying to resolve that blockage in this thread. Transparency is hard. Consensus is hard. It's messy, slow, and requires more patience and empathy than I want to dreg up myself most days. I think most if not all of our community would agree that transparency and consensus are things we want to have; the price for it is occasionally hitting frustrating overhead. It is a tradeoff. For me, this thread has unblocked what I needed it to unblock; the issues I wanted to work through are now moving forward in other places. So I'm done with this thread, and won't comment on it any longer, because this worksforme. That doesn't mean it worksforeveryone, though. And if it doesn't, and they continue this conversation because they still need to unblock themselves, I hope the remaining people on this thread will be constructive and help them work things out so that they, too, can Get On With Things they actually want to do. Over and out, --Mel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
On Thu, Sep 24, 2009 at 12:07:05PM -0400, metamel wrote: All I see is a lot of unproductive reinforcement of 4. let's talk a lot about tangential stuff to the detriment of letting SLOBs get on with answering the original question[1,2]. Patches welcome. You're replying to one. It seems to have failed to apply to your repo. I'm submitting to mainline, though, and perhaps you can explain how your repo differs to mainline, or mine? Or you'd like me to understand this and submit a patch to your repo as well? Does this terminology help this conversation? [What are you doing about what you're complaining about? - was Patches welcome] If you mean what's your contribution?, it's a) some soas commits, and b) the question that Sebastien asked, which hasn't been answered. By repeatedly asking a pertinent question of the body with standing, I hope to get an answer. But you seem to take my reply out of context: I'm replying to David, where he tried to summarise the progress from the question by pointing out lots of things - things that were not part of answering the question. I pointed this out. What's the problem? Process and product are both important; the former builds our capacity to get on with making the latter. Think of those sections of this thread as a review request for a decisionmaking protocol. Rather than generalizing I don't need this to nobody needs this, step back and think about why *somebody* (in this case, multiple somebodies) thought we needed something like it. What are they trying to accomplish? I highly doubt anyone here has the goal of talking a lot about tangential stuff No, but perhaps until it's pointed out that the conversation has degenerated into a tanget people will at least be motivated to change the subject at message #100-ish, so that those interested in the original question don't have to read tangents that can't be bothered to put a relevant subject. Or, if people _think_ they're still on topic, but the topic starters don't, then I think it's useful to point out this disconnect. transparency and consensus are things we want to have; the price for it is occasionally hitting frustrating overhead. It is a tradeoff. Fair enough. You may consider my reply as trying to improve the process next time by pointing out when the process - getting an answer and enjoying the journey to the answer - is no longer being served. Over and out, --Mel Martin pgpFq9DjZ5Ph1.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
Sebastien's original question[2] is unanswered perhaps because it's been deemed maybe-already-answered[3] or peripheral To the contrary, it seems to me that it remains unanswered only because it has been deemed a very important question, one worth formal consideration by a decision panel and the oversight board. Decision-making at SL is by consensus whenever possible (http://wiki.sugarlabs.org/go/Sugar_Labs/Governance#Decision_Panels). One indication of how well our community successfully empowers people to do the things they think will best help Sugar is how *rarely* we need Authority From Above to swoop down and tell us How Things Shall Be. Every time we clarify our thoughts and come to a conclusion together, we make a decision, *and* we improve our ability to make decisions in the future. The way we learn how to more rapidly and clearly make decisions by consensus is by practicing decision-making-by-consensus. It's a tough thing to learn, as is the art of being a do-ocracy (with coding as one of many ways of Doing Something). That's how I see it, anyway. Anyway, in the interests of Doing Stuff, I filed a mailing list creation ticket (ownership set to bernie since he's the Infrastructure lead) http://dev.sugarlabs.org/ticket/1419 to take care of 4.1, and to give us a place to do the rest. The next thing I'll do (this evening) is to find the What is a SL Project? thread, do a similar summary of where we stand / blockers, and try to nudge 4.2 and 4.4 onwards (though it looks like Sebastian's pretty much got things from here); it sounds like Marketing (led by Sean, who's made his thoughts clear in this thread) should be driving consensus on 4.3, or possibly counseling the Decision Panel on it if the SLOBs announce/appoint a decision panel with a chair and a deadline for making a specific choice. These are all suggestions that I happen to think make sense and plan on moving forward on in the hopes that others will join me or course-correct me. Pushback/patches welcome. ;-) --Mel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
Yes, thanks Mel Tomeu, it is certainly the case that I need clarity too, since the Sugar Labs message is part of a strategy designed to achieve massive adoption of Sugar beyond OLPC, while supporting the latter. Sugar on GNU/Linux alone cannot be a vector of massive adoption, but SoaS (as I defined it here: http://lists.sugarlabs.org/archive/iaep/2009-September/008557.html) can be, I am certain. May I add that this strategy is of course open to question... but every way I wrap my head around the problem, I arrive at the same conclusions. I could be wrong, but I believe that promoting multiple Sugar on liveUSB solutions will be counterproductive to that goal. We *could* attempt to promote several liveUSB solutions together as Sugar on a Stick, but the distro names will just add a layer of confusion to non-initiates and I'm afraid the idea of associating colors by distro will, too. Supporting different distro versions is bound to be confusing for teachers I think - how will they ever identify what version they have? And no teacher will understand someone from Sugar Labs telling them they have a Fedora problem, or an Ubuntu problem, or an openSuSE problem... they will want a solution to a Sugar on a Stick problem. That said, beyond our clear-as-a-bell marketing and promotion, I think alternative liveUSB versions should be welcome and indeed listed on the Try Sugar page. A final note. It's not just the Sugar Labs message, and the part of the community working on SoaS, which are impacted. It's SoaS deployments, led by Caroline who has been pointing out all the missing pieces of a successful deployment beyond the code. I believe that Caroline can help Sugar Labs develop a SoaS deployment template which can eventually be easily adapted by system integrators for schools, jump-starting an ecosystem. Feedback could be a key part of that template, but documentation, multiple stick loading, backup, school server, etc. have to be. Sean On Wed, Sep 23, 2009 at 2:46 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Wed, Sep 23, 2009 at 14:36, Mel Chua meta...@gmail.com wrote: Sebastien's original question[2] is unanswered perhaps because it's been deemed maybe-already-answered[3] or peripheral To the contrary, it seems to me that it remains unanswered only because it has been deemed a very important question, one worth formal consideration by a decision panel and the oversight board. Decision-making at SL is by consensus whenever possible (http://wiki.sugarlabs.org/go/Sugar_Labs/Governance#Decision_Panels). One indication of how well our community successfully empowers people to do the things they think will best help Sugar is how *rarely* we need Authority From Above to swoop down and tell us How Things Shall Be. Every time we clarify our thoughts and come to a conclusion together, we make a decision, *and* we improve our ability to make decisions in the future. The way we learn how to more rapidly and clearly make decisions by consensus is by practicing decision-making-by-consensus. It's a tough thing to learn, as is the art of being a do-ocracy (with coding as one of many ways of Doing Something). That's how I see it, anyway. Anyway, in the interests of Doing Stuff, I filed a mailing list creation ticket (ownership set to bernie since he's the Infrastructure lead) http://dev.sugarlabs.org/ticket/1419 to take care of 4.1, and to give us a place to do the rest. Thanks a lot for keep pushing things forward. The next thing I'll do (this evening) is to find the What is a SL Project? thread, do a similar summary of where we stand / blockers, and try to nudge 4.2 and 4.4 onwards (though it looks like Sebastian's pretty much got things from here); it sounds like Marketing (led by Sean, who's made his thoughts clear in this thread) should be driving consensus on 4.3, or possibly counseling the Decision Panel on it if the SLOBs announce/appoint a decision panel with a chair and a deadline for making a specific choice. My personal view on this is that this is a matter that affects mostly the marketing team _and_ the SoaS team. The former because they do the marketing of a product with that name, and the later because it's a community effort that has been using that name. I'm not talking about who has the right to define what SoaS means, but about which groups inside SLs need a decision on this to keep doing their work. Regards, Tomeu These are all suggestions that I happen to think make sense and plan on moving forward on in the hopes that others will join me or course-correct me. Pushback/patches welcome. ;-) --Mel ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
In my view, the mailing list should be called SoaS-Fedora. That's the specific project the mailing list is intended to support, and we haven't reached consensus that Sugar on a Stick should always refer to the Fedora liveUSB project. Although that's clearly the case today and for the forseeable future, as stated previously I think the moniker should be used for the best liveUSB Sugar available, should an easier to load-install-configure-troubleshoot alternate present itself. Sean. On Wed, Sep 23, 2009 at 2:36 PM, Mel Chua meta...@gmail.com wrote: Sebastien's original question[2] is unanswered perhaps because it's been deemed maybe-already-answered[3] or peripheral To the contrary, it seems to me that it remains unanswered only because it has been deemed a very important question, one worth formal consideration by a decision panel and the oversight board. Decision-making at SL is by consensus whenever possible (http://wiki.sugarlabs.org/go/Sugar_Labs/Governance#Decision_Panels). One indication of how well our community successfully empowers people to do the things they think will best help Sugar is how *rarely* we need Authority From Above to swoop down and tell us How Things Shall Be. Every time we clarify our thoughts and come to a conclusion together, we make a decision, *and* we improve our ability to make decisions in the future. The way we learn how to more rapidly and clearly make decisions by consensus is by practicing decision-making-by-consensus. It's a tough thing to learn, as is the art of being a do-ocracy (with coding as one of many ways of Doing Something). That's how I see it, anyway. Anyway, in the interests of Doing Stuff, I filed a mailing list creation ticket (ownership set to bernie since he's the Infrastructure lead) http://dev.sugarlabs.org/ticket/1419 to take care of 4.1, and to give us a place to do the rest. The next thing I'll do (this evening) is to find the What is a SL Project? thread, do a similar summary of where we stand / blockers, and try to nudge 4.2 and 4.4 onwards (though it looks like Sebastian's pretty much got things from here); it sounds like Marketing (led by Sean, who's made his thoughts clear in this thread) should be driving consensus on 4.3, or possibly counseling the Decision Panel on it if the SLOBs announce/appoint a decision panel with a chair and a deadline for making a specific choice. These are all suggestions that I happen to think make sense and plan on moving forward on in the hopes that others will join me or course-correct me. Pushback/patches welcome. ;-) --Mel ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
On Wed, Sep 23, 2009 at 3:58 PM, Sean DALY sdaly...@gmail.com wrote: In my view, the mailing list should be called SoaS-Fedora. That's the specific project the mailing list is intended to support, and we haven't reached consensus that Sugar on a Stick should always refer to the Fedora liveUSB project. Although that's clearly the case today and for the forseeable future, as stated previously I think the moniker should be used for the best liveUSB Sugar available, should an easier to load-install-configure-troubleshoot alternate present itself. I think it should just be called soas-list or soas-dev so that there's no direct connection to any specific distro so that if in the future that changes it doesn't affect the list, the archives or the membership lists. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
I thought about that, but in that case it wouldn't be appropriate for Sebastian or anyone associated with Fedora or any other distro for that matter to moderate the list; the moderator would need to be distro-independent. Would the list also be open to any alternate liveUSB Sugar project? This seems premature to me, what Sugar on a Stick refers to is still under discussion today without consensus (I am confident consensus is possible though, as drawn-out as it can be :-). Whereas Sebastian is running a great project with today's SoaS and that active project will I think benefit from a dedicated list despite Martin's reasonable misgivings about duplicate membership in many cases. Put another way, if an Ubuntu liveUSB project with great ease of use comes along, or Novell decides to push the openSuSE liveUSB through their education sales channel, or a Trisquel variant with a bulletproof stick loader and teacher-friendly setup screens turns out to run great, my position is that Sugar Labs should at least have the choice to put best foot forward with the best liveUSB project marketed as Sugar on a Stick. However, again, in all fairness to Sebastian and as stated previously, I think the existing liveUSB Fedora project is and should remain Sugar on a Stick for the forseeable future. So as to reassure Sebastian that no rug will be pulled out from under him, perhaps such a change could be scheduled? For example each year following Oversight Board elections, first potential change a year from now? All of which woud not preclude alternate liveUSB projects from appearing on the Try Sugar page (such alternate projects if very active, possibly having their own lists). The Marketing Team needs some certainty as much as the SoaS code contributors; surprises are always difficult to handle if different or contradictory from previous communications (a situation we dealt with in June, fortunately with a happy ending). Sean. On Wed, Sep 23, 2009 at 5:25 PM, Peter Robinson pbrobin...@gmail.com wrote: On Wed, Sep 23, 2009 at 3:58 PM, Sean DALY sdaly...@gmail.com wrote: In my view, the mailing list should be called SoaS-Fedora. That's the specific project the mailing list is intended to support, and we haven't reached consensus that Sugar on a Stick should always refer to the Fedora liveUSB project. Although that's clearly the case today and for the forseeable future, as stated previously I think the moniker should be used for the best liveUSB Sugar available, should an easier to load-install-configure-troubleshoot alternate present itself. I think it should just be called soas-list or soas-dev so that there's no direct connection to any specific distro so that if in the future that changes it doesn't affect the list, the archives or the membership lists. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
On Wed, Sep 23, 2009 at 4:55 PM, Sean DALY sdaly...@gmail.com wrote: I thought about that, but in that case it wouldn't be appropriate for Sebastian or anyone associated with Fedora or any other distro for that matter to moderate the list; the moderator would need to be distro-independent. Would the list also be open to any alternate liveUSB Sugar project? This seems premature to me, what Sugar on a Stick refers to is still under discussion today without consensus (I am confident consensus is possible though, as drawn-out as it can be :-). Whereas Sebastian is running a great project with today's SoaS and that active project will I think benefit from a dedicated list despite Martin's reasonable misgivings about duplicate membership in many cases. Put another way, if an Ubuntu liveUSB project with great ease of use comes along, or Novell decides to push the openSuSE liveUSB through their education sales channel, or a Trisquel variant with a bulletproof stick loader and teacher-friendly setup screens turns out to run great, my position is that Sugar Labs should at least have the choice to put best foot forward with the best liveUSB project marketed as Sugar on a Stick. However, again, in all fairness to Sebastian and as stated previously, I think the existing liveUSB Fedora project is and should remain Sugar on a Stick for the forseeable future. So as to reassure Sebastian that no rug will be pulled out from under him, perhaps such a change could be scheduled? For example each year following Oversight Board elections, first potential change a year from now? All of which woud not preclude alternate liveUSB projects from appearing on the Try Sugar page (such alternate projects if very active, possibly having their own lists). The Marketing Team needs some certainty as much as the SoaS code contributors; surprises are always difficult to handle if different or contradictory from previous communications (a situation we dealt with in June, fortunately with a happy ending). You read a lot into the name of a mailing list. What has the name of a mailing list for _developers_ got to do with _martketing_..? Nothing! And by keeping it generic you get the advantage that if it changes to SuSE or the latest and greatest distro that hasn't yet been invented it doesn't matter. We already have a fedora-olpc list on the fedora list servers. ultimately keep the name generic and that way you keep it the same if the tech stuff change.. that's the best marketing as it will be forever that in google. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
But marketing discussions are already on the Sugar Labs marketing list. There's Sugar Labs marketing, nothing specific to SoaS. SoaS is the pillar of the marketing strategy, but in the Sugar Labs picture. The mailing list in question is for developers... on the specific existing project. Googling Sugar on a Stick will find (as it finds today) the Sugar Labs website and the download page. Sean On Wed, Sep 23, 2009 at 6:00 PM, Peter Robinson pbrobin...@gmail.com wrote: On Wed, Sep 23, 2009 at 4:55 PM, Sean DALY sdaly...@gmail.com wrote: I thought about that, but in that case it wouldn't be appropriate for Sebastian or anyone associated with Fedora or any other distro for that matter to moderate the list; the moderator would need to be distro-independent. Would the list also be open to any alternate liveUSB Sugar project? This seems premature to me, what Sugar on a Stick refers to is still under discussion today without consensus (I am confident consensus is possible though, as drawn-out as it can be :-). Whereas Sebastian is running a great project with today's SoaS and that active project will I think benefit from a dedicated list despite Martin's reasonable misgivings about duplicate membership in many cases. Put another way, if an Ubuntu liveUSB project with great ease of use comes along, or Novell decides to push the openSuSE liveUSB through their education sales channel, or a Trisquel variant with a bulletproof stick loader and teacher-friendly setup screens turns out to run great, my position is that Sugar Labs should at least have the choice to put best foot forward with the best liveUSB project marketed as Sugar on a Stick. However, again, in all fairness to Sebastian and as stated previously, I think the existing liveUSB Fedora project is and should remain Sugar on a Stick for the forseeable future. So as to reassure Sebastian that no rug will be pulled out from under him, perhaps such a change could be scheduled? For example each year following Oversight Board elections, first potential change a year from now? All of which woud not preclude alternate liveUSB projects from appearing on the Try Sugar page (such alternate projects if very active, possibly having their own lists). The Marketing Team needs some certainty as much as the SoaS code contributors; surprises are always difficult to handle if different or contradictory from previous communications (a situation we dealt with in June, fortunately with a happy ending). You read a lot into the name of a mailing list. What has the name of a mailing list for _developers_ got to do with _martketing_..? Nothing! And by keeping it generic you get the advantage that if it changes to SuSE or the latest and greatest distro that hasn't yet been invented it doesn't matter. We already have a fedora-olpc list on the fedora list servers. ultimately keep the name generic and that way you keep it the same if the tech stuff change.. that's the best marketing as it will be forever that in google. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
Mel, Sebastian, Walter, Bernie, David and the others, thanks for that ad-hoc yet fruitful IRC discussion tonight. I trust someone can post the transcript? Meetbot seemed revived. I fully support the new list as a gathering place for any liveUSB Sugar project, even if Sebastian's project is and will remain Sugar on a Stick for the forseeable future. I think we're in phase about that. I also like the idea of a SoaS Steering Committee, composed of educators, not necessarily geeky, perhaps prominent, who could bring constructively critical input. I'm not sure how this fits in with the charter though, and the Decision Panel etc. I am confident we are working through the issues. It may seem like much ado about nothing, but the clarity now will be helpful as we grow (perhaps quickly). thanks Sean On Wed, Sep 23, 2009 at 8:10 PM, Mel Chua meta...@gmail.com wrote: The mailing list in question is for developers... on the specific existing project. Googling Sugar on a Stick will find (as it finds today) the Sugar Labs website and the download page. I interpreted the mailing list in question as being primarily for developers of *any* SoaS, with the current Fedora-based solution making up the bulk of that discussion at the moment. (I'd still expect users to be directed towards iaep, unless they wanted to do SoaS-specific testing - and for Marketing to be able to decide what the name SoaS points towards.) I've tried to clarify this in http://dev.sugarlabs.org/ticket/1419 - Sean, does this address your concerns? It's going to be tough to find someone in the SL community who is distro-independent (most of us at least have one slightly preferred distro-of-the-moment, if we're not already more involved with our distro community). I think it is sufficient for the s...@lists.sugarlabs.org list moderator to acknowledge the need for distro-neutrality for the generic SoaS term, and be open to any alternate liveUSB Sugar project.* Sean, since you are concerned about distro neutrality and clarity around the marketing of SoaS, would you like to be the mailing list admin (or a moderator)? If you read the ticket, you'll see me looking for Somebody Better to manage the soas@ list. (Mailing list mod/adminship is Not A Big Deal, and the Infrastructure team can step in if things go way downhill; it's mostly making sure spam doesn't drown us all, and cutting off flamewars when they're not dying down by themselves; a good list should rarely, if ever, need to have the latter part enforced) --Mel *...any alternate liveUSB Sugar project that has been through the hypothetical future lightweight approval for usage of the SoaS trademark (which we should also hypothetically have in the future), that is. But these are both entirely different topics. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
Thanks for the update, Sean! The mailing list is up - details on the conversation are posted at http://wiki.sugarlabs.org/go/Talk:Sugar_on_a_Stick#Make_a_SoaS_mailing_list. In short: people talked, consensus was reached, stuff happened. We're getting better at this - and are close to finishing these discussions. In an attempt to wrap up this thread, I'm going to split the remaining open items into the separate issues they've become. Everything is summarized on the (somewhat heavily updated now, to reflect all the discussion that have been taking place to the best of my knowledge) wiki page, http://wiki.sugarlabs.org/go/Talk:Sugar_on_a_Stick. These two items are moving to separate threads on the new SoaS mailing list. * 4.1 Formalize a SoaS development team has turned into http://wiki.sugarlabs.org/go/Talk:Sugar_on_a_Stick#Formalize_what_SL_project_status_means_for_SoaS_spins, discussed in http://lists.sugarlabs.org/archive/soas/2009-September/00.html. * 4.3 Determine what the code Sebastian is working on has turned into http://wiki.sugarlabs.org/go/Talk:Sugar_on_a_Stick#Generate_a_list_of_SoaS_spins, discussed in http://lists.sugarlabs.org/archive/soas/2009-September/01.html. This item has already moved to a separate thread: * 4.2 Determine what Sugar on a Stick refers to (See http://lists.sugarlabs.org/archive/sugar-devel/2009-September/019548.html - the panel will be selected - and I assume receive their charge and a deadline - at this Friday's SLOBs meeting.) As far as I can tell, this closes out this particular thread of epic marathoning - I hope we're moving quickly enough to keep folks from getting too impatient, while still giving people (particularly ones with busy day jobs/studies that aren't Sugar 24/7) a chance to read and respond and help us reach consensus. --Mel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
On Tue, Sep 22, 2009 at 01:03:37AM -0400, Mel Chua wrote: Ok - then the situation is this, then: http://wiki.sugarlabs.org/index.php?title=Talk%3ASugar_on_a_Stickdiff=37874oldid=37820 It looks like the SoaS team is unblocked I don't see how the SoaS team was ever blocked on the things that are now unblocked (mailing list, start team/SL project). Sebastien was just going to do them[1]. Sebastien's original question[2] is unanswered perhaps because it's been deemed maybe-already-answered[3] or peripheral (your page) despite being important[4,5,6] and the fact that the thread is now over a hundred messages long. It's a week and a bit after the original mail already. This is a convincing demonstration of the utter failure in decision-making. I'm going to fall back on Daniel's advice[7] about letting the code do the talking, but I hope that the people that don't have this option get a better deal next time they need something clarified by SL. It's not hard to say no, but it takes a mailing list and a committee to really avoid saying it for so long and with such obfuscation, it seems. --Mel Martin 1. http://lists.sugarlabs.org/archive/iaep/2009-September/008322.html 2. http://lists.sugarlabs.org/archive/iaep/2009-September/008373.html 3. http://lists.sugarlabs.org/archive/iaep/2009-September/008387.html 4. http://lists.sugarlabs.org/archive/iaep/2009-September/008374.html 5. http://lists.sugarlabs.org/archive/iaep/2009-September/008386.html 6. http://lists.sugarlabs.org/archive/iaep/2009-September/008405.html 7. http://lists.sugarlabs.org/archive/iaep/2009-September/008404.html ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep pgpMe47cMfCuC.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
On Tue, Sep 22, 2009 at 07:35:25AM +0100, Martin Dengler wrote: This is a convincing demonstration of the utter failure in decision-making. This is overly harsh, sorry. Martin pgpwsJuO6ML8E.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
On Tue, Sep 22, 2009 at 2:35 AM, Martin Dengler mar...@martindengler.com wrote: On Tue, Sep 22, 2009 at 01:03:37AM -0400, Mel Chua wrote: Sebastien's original question[2] is unanswered perhaps because it's been deemed maybe-already-answered[3] or peripheral To the contrary, it seems to me that it remains unanswered only because it has been deemed a very important question, one worth formal consideration by a decision panel and the oversight board. It's a week and a bit after the original mail already. This is a convincing demonstration of the utter failure in decision-making. Impatient as ever :-)If this is in fact an important question to the future of Sugar and SoaS development, taking time to answer it unambiguously may be wise. It's not hard to say no, but it takes a mailing list and a committee Replies so far have been varied, but they do not sound like no to me. SJ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
Mel Chua wrote: There's a lot going on in this thread, so here is my attempt to summarize discussions so far. If I've missed or misstated anything, my apologies - and it's a wiki, so go fix it. ;-) http://wiki.sugarlabs.org/go/Talk:Sugar_on_a_Stick By my count, there are 4 things we need to decide on and then execute in order to wrap up this conversation. Some are already in progress. * 4.1 Make a SoaS mailing list * 4.2 Formalize a SoaS development team * 4.3 Determine what Sugar on a Stick refers to * 4.4 Determine what the code Sebastian is working on is called Only the third one has a clear owner (SLOBs) and can be decided at this time (the 4th seems to depend on the answer to the 3rd). How can we move these forward - and are there any other blocker decisions that aren't listed here? --Mel, the human ticket tracker Ahhh! Sorry, I'm a bit late to this party here... Mel, this talk and the summary page is *awesome* - thanks a lot for getting everything together there! I agree that most of the other parts are non-blocking - at least for 4.1 4.2 we probably don't need a SLOBs decision, right? - while 4.3 is something that still needs to be solved (4.4 is related to it, I'd say). --Sebastian ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
I can understand why a teacher may not be interested in this discussion. Still, the debate is also very relevant. It's about how we're going to address your aunt's concerns. The debate is definitely very relevant, and I'm glad we're having it. Think of it this way: nobody wants to know how sausage is made, right? Well, we're the sausage factory! :-) To run with this analogy for a moment - what the conversation with my aunt reminded me of was this: while we sit here talking, there are hungry people out there. And the time we use to discuss the optimization of our sausage-making setup is time we are *not* spending making sausage that those people can eat. It's not a reason to stop having these discussions - they *are* needed - but it is (imo) something we should be painfully aware of every time we do. A sausage factory with beautifully optimized machines, happy skilled workers, etc. is a nice theoretical setup for a great sausage factory - but it's the production of sausage and its consumption by satisfied diners that turns it into an *actual* great sausage factory. So a litmus test for conversations in this thread (and other SLs) might be: Is this action I am about to take the best use of my time towards helping children learn? And on that note, my next post will be a summary of the thread to date so that (hopefully) we can see what's left to do in order to move forward on this. --Mel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
There's a lot going on in this thread, so here is my attempt to summarize discussions so far. If I've missed or misstated anything, my apologies - and it's a wiki, so go fix it. ;-) http://wiki.sugarlabs.org/go/Talk:Sugar_on_a_Stick By my count, there are 4 things we need to decide on and then execute in order to wrap up this conversation. Some are already in progress. * 4.1 Make a SoaS mailing list * 4.2 Formalize a SoaS development team * 4.3 Determine what Sugar on a Stick refers to * 4.4 Determine what the code Sebastian is working on is called Only the third one has a clear owner (SLOBs) and can be decided at this time (the 4th seems to depend on the answer to the 3rd). How can we move these forward - and are there any other blocker decisions that aren't listed here? --Mel, the human ticket tracker ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
On Mon, Sep 21, 2009 at 08:30, Mel Chua meta...@gmail.com wrote: There's a lot going on in this thread, so here is my attempt to summarize discussions so far. If I've missed or misstated anything, my apologies - and it's a wiki, so go fix it. ;-) http://wiki.sugarlabs.org/go/Talk:Sugar_on_a_Stick By my count, there are 4 things we need to decide on and then execute in order to wrap up this conversation. Some are already in progress. * 4.1 Make a SoaS mailing list * 4.2 Formalize a SoaS development team * 4.3 Determine what Sugar on a Stick refers to * 4.4 Determine what the code Sebastian is working on is called Only the third one has a clear owner (SLOBs) and can be decided at this time (the 4th seems to depend on the answer to the 3rd). How can we move these forward - and are there any other blocker decisions that aren't listed here? Great summary, this is my understanding of how things stand today: 4.1 can be left entirely to the SoaS team for decide 4.2 also depends only on the SoaS team, haven't heard nobody against SoaS qualifying for a project inside SLs. SoaS is already listed as a project in the wiki, btw: http://wiki.sugarlabs.org/go/Category:Project http://wiki.sugarlabs.org/go/Sugar_Labs/Project_Guidelines 4.3 a decision panel has been proposed to help with this 4.4 only depends on the SoaS team, but may depend on 4.3 to avoid name clashes Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
On Mon, Sep 21, 2009 at 3:37 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Mon, Sep 21, 2009 at 08:30, Mel Chua meta...@gmail.com wrote: There's a lot going on in this thread, so here is my attempt to summarize discussions so far. If I've missed or misstated anything, my apologies - and it's a wiki, so go fix it. ;-) http://wiki.sugarlabs.org/go/Talk:Sugar_on_a_Stick By my count, there are 4 things we need to decide on and then execute in order to wrap up this conversation. Some are already in progress. * 4.1 Make a SoaS mailing list * 4.2 Formalize a SoaS development team * 4.3 Determine what Sugar on a Stick refers to * 4.4 Determine what the code Sebastian is working on is called Only the third one has a clear owner (SLOBs) and can be decided at this time (the 4th seems to depend on the answer to the 3rd). How can we move these forward - and are there any other blocker decisions that aren't listed here? Great summary, this is my understanding of how things stand today: 4.1 can be left entirely to the SoaS team for decide 4.2 also depends only on the SoaS team, haven't heard nobody against SoaS qualifying for a project inside SLs. SoaS is already listed as a project in the wiki, btw: http://wiki.sugarlabs.org/go/Category:Project http://wiki.sugarlabs.org/go/Sugar_Labs/Project_Guidelines 4.3 a decision panel has been proposed to help with this 4.4 only depends on the SoaS team, but may depend on 4.3 to avoid name clashes Regards, After reading this thread again, Mel's and Tomeu's summaries are spot on. 1,2, and 4 are SoaS Project level decisions. We could go even one step further and say 4.3 is a marketing team/soas project level decision. This give the marketing team the freedom to identify a marketing strategy base on either the platform of a specific project with the overall project without committing the Sugar Labs to a 'official' position david ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
Hi Mel that wiki page is helpful To my knowledge, Sugar on a Stick has not been trademarked yet by Sugar Labs; my position is that it should be. Sugar on a Stick is the heart of the Sugar Labs strategy for spreading Sugar use beyond OLPC. Although other technical solutions are promising, at this time they don't come close to matching the advantages of the SoaS approach, in particular its conceptual simplicity to nongeeks. SoaS overcomes the single biggest obstacle to easily running any non-Microsoft system software on PCs and netbooks: the installation barrier. Our short definition of SoaS should be immediately intelligible to teachers, in my view. Most teachers won't care if Sugar runs on GNU/Linux, but they will care very much about its cost, reliability, and level of technical competence required to obtain/install/configure/test it and obtain support throughout. How about: Sugar on a Stick is a version of the Sugar Learning Platform for children which runs from an ordinary USB stick. It is meant for 1-to-1 use in schools and at home, providing a coherent and consistent computing experience. Based on GNU/Linux, SoaS is free/libre open-source software focused on reliability, customizability, deployability, and online and local support. If we can agree on this definition, we are on the road to agreeing on what SoaS is from a technical standpoint. As stated previously I think the 'best' liveUSB should represent Sugar Labs. Which doesn't preclude listing other liveUSB Sugars, but teachers will need a dead simple path from homepage to pancake-button download to installer/USB loader to boot and configure. Sean On 9/21/09, Tomeu Vizoso to...@sugarlabs.org wrote: On Mon, Sep 21, 2009 at 08:30, Mel Chua meta...@gmail.com wrote: There's a lot going on in this thread, so here is my attempt to summarize discussions so far. If I've missed or misstated anything, my apologies - and it's a wiki, so go fix it. ;-) http://wiki.sugarlabs.org/go/Talk:Sugar_on_a_Stick By my count, there are 4 things we need to decide on and then execute in order to wrap up this conversation. Some are already in progress. * 4.1 Make a SoaS mailing list * 4.2 Formalize a SoaS development team * 4.3 Determine what Sugar on a Stick refers to * 4.4 Determine what the code Sebastian is working on is called Only the third one has a clear owner (SLOBs) and can be decided at this time (the 4th seems to depend on the answer to the 3rd). How can we move these forward - and are there any other blocker decisions that aren't listed here? Great summary, this is my understanding of how things stand today: 4.1 can be left entirely to the SoaS team for decide 4.2 also depends only on the SoaS team, haven't heard nobody against SoaS qualifying for a project inside SLs. SoaS is already listed as a project in the wiki, btw: http://wiki.sugarlabs.org/go/Category:Project http://wiki.sugarlabs.org/go/Sugar_Labs/Project_Guidelines 4.3 a decision panel has been proposed to help with this 4.4 only depends on the SoaS team, but may depend on 4.3 to avoid name clashes Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
Ok - then the situation is this, then: http://wiki.sugarlabs.org/index.php?title=Talk%3ASugar_on_a_Stickdiff=37874oldid=37820 It looks like the SoaS team is unblocked - now all that remains is for the SoaS team members to identify themselves (I'd suggest just requesting and joining a separate mailing list) and go about making these decisions so we can get on with making SoaS. ;-) --Mel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
This is exactly the kind of feedback SoaS and deployment teams need. Kudos! Art Hunkins - Original Message - From: Mel Chua m...@melchua.com To: i...@lists.sugarlabs.org; Sugar Devel sugar-devel@lists.sugarlabs.org Sent: Thursday, September 17, 2009 11:38 PM Subject: Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick I read the multiple future of SoaS discussions on this mailing list and... to be honest, I was frustrated and didn't quite know how to respond. So I called my aunt Lynne May (I stay with her family when I'm in Boston). She's been a teacher for over 15 years. She teaches first grade. (I've been showing her Sugar occasionally for the past 2 years, and she thinks it's very cool.) I described this thread to her, explained the situation, and asked for her perspective. The summary of it was: This discussion you are having, as important as it may be to you, makes no difference to me as a teacher. Here is what does. Here are our notes - written up to the best of my ability, and then read over and edited (and added to) by her. I haven't edited anything out, so it's quite long.. I hope that others will be able to pull out the points that caught their eye, because I am not sure what in here will be most interesting to people. What teachers care about: * Is it friendly? * Is it consistent? * Is it sustainable? What they DON'T care about: * What group runs it? * Who owns the trademark? * What bleeding-edge features are being developed now for a future release? * What is the underlying operating system (which they never see)? Let's go into each of these topics in turn. Friendly. Is there a one-stop shop I can go to where my problems will be fixed immediately? Yes, theoretically it's possible to chase down the problem yourself, since everything is open source. And yes, you don't need technical knowledge because eventually, if you keep asking questions and trace things back to the appropriate developers in the appropriate upstreams, you'll likely find someone friendly to fix it for you. However, even if the individual developers are friendly - and we have very friendly, helpful developers - the process is not. Teachers don't have time to chase issues down the rabbit hole. They need to be able to report an issue and then know when that issue will be fixed by, so they know how long they have to improvise for. Consistent. It's important to have the experience be consistent for the kids. When are we going to do that thing again? they'll ask. It needs to work - and work the same way - every week. Kids hold you accountable for being consistent. They're in the classroom every single day. Teachers are also in the classroom every single day, and on-call every hour of that day. They also need consistency. Teachers improvise a lot, but they can only do so if they know what tools they have available, and that those tools can be relied upon. They set aside prep time; they have to know that they won't need to spend more than X hours per week to prep for this. If they can't predict how much time it will take to use a tool each week, they won't be able to use it. Tools need to be consistent from day to day, but also from year to year. Will they need to relearn a new toolset next year? She relayed a story about choosing the reading assessment tool the first grade team will use this school year. Should they use the same assessment program used in previous year even if there are missing books in the current set? Or should they switch to a different assessment program. It took them only 20 minutes total to make a decision. They based their decision on the consistency factor, affordability, and immediate response by customer service to their query which helped them solve the problem of having an incomplete assessment kit. The final selection was the same program that was being used in other grade levels, and the same program that was previously used. The takeaway I got from this story is that sometimes it isn't the design of the tool itself that makes it better for the classroom - sometimes its the deployability, and a big condition of that deployability is how it fits into the things that other teachers are doing and the other tools the same teacher will be using. Things beyond our control. (And usually beyond theirs.) We have to remember that Sugar will be one of many tools going into a classroom; teachers aren't just going to be deploying Sugar to their kids, they're also going to be deploying this math book, or that reading set, this Spanish programme, that alphabet chart, this counting-blocks set, this easel... And the support experience needs to be consistent. As explained above, teachers need to know that no matter what their problem is, if they spend 2 minutes reporting it at this location, it will be fixed N days later. And as soon as they've spent 2 minutes reporting it, they need immediate feedback
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
On Fri, Sep 18, 2009 at 05:38, Mel Chua m...@melchua.com wrote: I read the multiple future of SoaS discussions on this mailing list and... to be honest, I was frustrated and didn't quite know how to respond. So I called my aunt Lynne May (I stay with her family when I'm in Boston). She's been a teacher for over 15 years. She teaches first grade. (I've been showing her Sugar occasionally for the past 2 years, and she thinks it's very cool.) I described this thread to her, explained the situation, and asked for her perspective. The summary of it was: This discussion you are having, as important as it may be to you, makes no difference to me as a teacher. Here is what does. Here are our notes - written up to the best of my ability, and then read over and edited (and added to) by her. I haven't edited anything out, so it's quite long.. I hope that others will be able to pull out the points that caught their eye, because I am not sure what in here will be most interesting to people. What teachers care about: * Is it friendly? * Is it consistent? * Is it sustainable? What they DON'T care about: * What group runs it? * Who owns the trademark? * What bleeding-edge features are being developed now for a future release? * What is the underlying operating system (which they never see)? Let's go into each of these topics in turn. Friendly. Is there a one-stop shop I can go to where my problems will be fixed immediately? Yes, theoretically it's possible to chase down the problem yourself, since everything is open source. And yes, you don't need technical knowledge because eventually, if you keep asking questions and trace things back to the appropriate developers in the appropriate upstreams, you'll likely find someone friendly to fix it for you. However, even if the individual developers are friendly - and we have very friendly, helpful developers - the process is not. Teachers don't have time to chase issues down the rabbit hole. They need to be able to report an issue and then know when that issue will be fixed by, so they know how long they have to improvise for. Consistent. It's important to have the experience be consistent for the kids. When are we going to do that thing again? they'll ask. It needs to work - and work the same way - every week. Kids hold you accountable for being consistent. They're in the classroom every single day. Teachers are also in the classroom every single day, and on-call every hour of that day. They also need consistency. Teachers improvise a lot, but they can only do so if they know what tools they have available, and that those tools can be relied upon. They set aside prep time; they have to know that they won't need to spend more than X hours per week to prep for this. If they can't predict how much time it will take to use a tool each week, they won't be able to use it. Tools need to be consistent from day to day, but also from year to year. Will they need to relearn a new toolset next year? She relayed a story about choosing the reading assessment tool the first grade team will use this school year. Should they use the same assessment program used in previous year even if there are missing books in the current set? Or should they switch to a different assessment program. It took them only 20 minutes total to make a decision. They based their decision on the consistency factor, affordability, and immediate response by customer service to their query which helped them solve the problem of having an incomplete assessment kit. The final selection was the same program that was being used in other grade levels, and the same program that was previously used. The takeaway I got from this story is that sometimes it isn't the design of the tool itself that makes it better for the classroom - sometimes its the deployability, and a big condition of that deployability is how it fits into the things that other teachers are doing and the other tools the same teacher will be using. Things beyond our control. (And usually beyond theirs.) We have to remember that Sugar will be one of many tools going into a classroom; teachers aren't just going to be deploying Sugar to their kids, they're also going to be deploying this math book, or that reading set, this Spanish programme, that alphabet chart, this counting-blocks set, this easel... And the support experience needs to be consistent. As explained above, teachers need to know that no matter what their problem is, if they spend 2 minutes reporting it at this location, it will be fixed N days later. And as soon as they've spent 2 minutes reporting it, they need immediate feedback and reassurance that yes, it's going to be fixed N days later; you were heard. It's not a fear of learning new things. It's being smart about wanting to know what returns on investment you can expect. It's silly to not know and limit how much it will cost (in terms of time) to
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
Mel - thanks for this delightful and thoughtful post. I agree with most of the points you and your aunt raise. Ben says, about 'Friendly' and 'Consistent': These two things sound pretty much the same to me. They also sound absolutely impossible, taken strictly. Taking a more relaxed interpretation, you seem to be describing, in effect, a full-time professional support staff. I disagree. As Tomeu points out, the SOAS community is organized around an idea that supports friendliness and consistency. To the comments that Gnome and KDE don't handle end to end packaging, the lack of almost any distors that are targeted effectively at these needs of teachers makes it important for some group to do it. I would find it a refreshing counterpoint to have a group in this ecosystem focused on maintaining a toolchain that first prioritizes the overall teacher and classroom experience, and second prioritizes hardware, OS, and software details. Some of its core releases / components / packages (for instance, a new social procedural system for getting help or processing feedback) might not involve a single transistor or line of code. SJ On Thu, Sep 17, 2009 at 11:38 PM, Mel Chua m...@melchua.com wrote: I read the multiple future of SoaS discussions on this mailing list and... to be honest, I was frustrated and didn't quite know how to respond. So I called my aunt Lynne May (I stay with her family when I'm in Boston). She's been a teacher for over 15 years. She teaches first grade. (I've been showing her Sugar occasionally for the past 2 years, and she thinks it's very cool.) I described this thread to her, explained the situation, and asked for her perspective. The summary of it was: This discussion you are having, as important as it may be to you, makes no difference to me as a teacher. Here is what does. Here are our notes - written up to the best of my ability, and then read over and edited (and added to) by her. I haven't edited anything out, so it's quite long.. I hope that others will be able to pull out the points that caught their eye, because I am not sure what in here will be most interesting to people. What teachers care about: * Is it friendly? * Is it consistent? * Is it sustainable? What they DON'T care about: * What group runs it? * Who owns the trademark? * What bleeding-edge features are being developed now for a future release? * What is the underlying operating system (which they never see)? Let's go into each of these topics in turn. Friendly. Is there a one-stop shop I can go to where my problems will be fixed immediately? Yes, theoretically it's possible to chase down the problem yourself, since everything is open source. And yes, you don't need technical knowledge because eventually, if you keep asking questions and trace things back to the appropriate developers in the appropriate upstreams, you'll likely find someone friendly to fix it for you. However, even if the individual developers are friendly - and we have very friendly, helpful developers - the process is not. Teachers don't have time to chase issues down the rabbit hole. They need to be able to report an issue and then know when that issue will be fixed by, so they know how long they have to improvise for. Consistent. It's important to have the experience be consistent for the kids. When are we going to do that thing again? they'll ask. It needs to work - and work the same way - every week. Kids hold you accountable for being consistent. They're in the classroom every single day. Teachers are also in the classroom every single day, and on-call every hour of that day. They also need consistency. Teachers improvise a lot, but they can only do so if they know what tools they have available, and that those tools can be relied upon. They set aside prep time; they have to know that they won't need to spend more than X hours per week to prep for this. If they can't predict how much time it will take to use a tool each week, they won't be able to use it. Tools need to be consistent from day to day, but also from year to year. Will they need to relearn a new toolset next year? She relayed a story about choosing the reading assessment tool the first grade team will use this school year. Should they use the same assessment program used in previous year even if there are missing books in the current set? Or should they switch to a different assessment program. It took them only 20 minutes total to make a decision. They based their decision on the consistency factor, affordability, and immediate response by customer service to their query which helped them solve the problem of having an incomplete assessment kit. The final selection was the same program that was being used in other grade levels, and the same program that was previously used. The takeaway I got from this story is that sometimes it isn't the design of the tool itself that makes it better for the
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
On Fri, Sep 18, 2009 at 10:21:34AM -0400, Art Hunkins wrote: From: Mel Chua m...@melchua.com [make SoaS friendly/consistent/sustainable] This is exactly the kind of feedback SoaS and deployment teams need. Kudos! I'm not sure why you see it as relevant. You're only right insofar as SoaS aims to make an un-friendly, inconsistent, unsustainable GNU/Linux distribution. In any case, that's hardly the topic at hand. Otherwise it certainly doesn't mean the original question should not be discussed. Art Hunkins Martin pgppBU56RCV8E.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
I think you're right on the money. I can understand why a teacher may not be interested in this discussion. Still, the debate is also very relevant. It's about how we're going to address your aunt's concerns. Think of it this way: nobody wants to know how sausage is made, right? Well, we're the sausage factory! :-) -- Philippe -- The trouble with common sense is that it is so uncommon. Anonymous On Thursday 17 September 2009 22:38:32 Mel Chua wrote: I read the multiple future of SoaS discussions on this mailing list and... to be honest, I was frustrated and didn't quite know how to respond. So I called my aunt Lynne May (I stay with her family when I'm in Boston). She's been a teacher for over 15 years. She teaches first grade. (I've been showing her Sugar occasionally for the past 2 years, and she thinks it's very cool.) I described this thread to her, explained the situation, and asked for her perspective. The summary of it was: This discussion you are having, as important as it may be to you, makes no difference to me as a teacher. Here is what does. Here are our notes - written up to the best of my ability, and then read over and edited (and added to) by her. I haven't edited anything out, so it's quite long.. I hope that others will be able to pull out the points that caught their eye, because I am not sure what in here will be most interesting to people. What teachers care about: * Is it friendly? * Is it consistent? * Is it sustainable? What they DON'T care about: * What group runs it? * Who owns the trademark? * What bleeding-edge features are being developed now for a future release? * What is the underlying operating system (which they never see)? Let's go into each of these topics in turn. Friendly. Is there a one-stop shop I can go to where my problems will be fixed immediately? Yes, theoretically it's possible to chase down the problem yourself, since everything is open source. And yes, you don't need technical knowledge because eventually, if you keep asking questions and trace things back to the appropriate developers in the appropriate upstreams, you'll likely find someone friendly to fix it for you. However, even if the individual developers are friendly - and we have very friendly, helpful developers - the process is not. Teachers don't have time to chase issues down the rabbit hole. They need to be able to report an issue and then know when that issue will be fixed by, so they know how long they have to improvise for. Consistent. It's important to have the experience be consistent for the kids. When are we going to do that thing again? they'll ask. It needs to work - and work the same way - every week. Kids hold you accountable for being consistent. They're in the classroom every single day. Teachers are also in the classroom every single day, and on-call every hour of that day. They also need consistency. Teachers improvise a lot, but they can only do so if they know what tools they have available, and that those tools can be relied upon. They set aside prep time; they have to know that they won't need to spend more than X hours per week to prep for this. If they can't predict how much time it will take to use a tool each week, they won't be able to use it. Tools need to be consistent from day to day, but also from year to year. Will they need to relearn a new toolset next year? She relayed a story about choosing the reading assessment tool the first grade team will use this school year. Should they use the same assessment program used in previous year even if there are missing books in the current set? Or should they switch to a different assessment program. It took them only 20 minutes total to make a decision. They based their decision on the consistency factor, affordability, and immediate response by customer service to their query which helped them solve the problem of having an incomplete assessment kit. The final selection was the same program that was being used in other grade levels, and the same program that was previously used. The takeaway I got from this story is that sometimes it isn't the design of the tool itself that makes it better for the classroom - sometimes its the deployability, and a big condition of that deployability is how it fits into the things that other teachers are doing and the other tools the same teacher will be using. Things beyond our control. (And usually beyond theirs.) We have to remember that Sugar will be one of many tools going into a classroom; teachers aren't just going to be deploying Sugar to their kids, they're also going to be deploying this math book, or that reading set, this Spanish programme, that alphabet chart, this counting-blocks set, this easel... And the support experience needs to be consistent. As explained above, teachers need to know that no matter what their problem is, if they spend 2 minutes
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
I read the multiple future of SoaS discussions on this mailing list and... to be honest, I was frustrated and didn't quite know how to respond. So I called my aunt Lynne May (I stay with her family when I'm in Boston). She's been a teacher for over 15 years. She teaches first grade. (I've been showing her Sugar occasionally for the past 2 years, and she thinks it's very cool.) I described this thread to her, explained the situation, and asked for her perspective. The summary of it was: This discussion you are having, as important as it may be to you, makes no difference to me as a teacher. Here is what does. Here are our notes - written up to the best of my ability, and then read over and edited (and added to) by her. I haven't edited anything out, so it's quite long.. I hope that others will be able to pull out the points that caught their eye, because I am not sure what in here will be most interesting to people. What teachers care about: * Is it friendly? * Is it consistent? * Is it sustainable? What they DON'T care about: * What group runs it? * Who owns the trademark? * What bleeding-edge features are being developed now for a future release? * What is the underlying operating system (which they never see)? Let's go into each of these topics in turn. Friendly. Is there a one-stop shop I can go to where my problems will be fixed immediately? Yes, theoretically it's possible to chase down the problem yourself, since everything is open source. And yes, you don't need technical knowledge because eventually, if you keep asking questions and trace things back to the appropriate developers in the appropriate upstreams, you'll likely find someone friendly to fix it for you. However, even if the individual developers are friendly - and we have very friendly, helpful developers - the process is not. Teachers don't have time to chase issues down the rabbit hole. They need to be able to report an issue and then know when that issue will be fixed by, so they know how long they have to improvise for. Consistent. It's important to have the experience be consistent for the kids. When are we going to do that thing again? they'll ask. It needs to work - and work the same way - every week. Kids hold you accountable for being consistent. They're in the classroom every single day. Teachers are also in the classroom every single day, and on-call every hour of that day. They also need consistency. Teachers improvise a lot, but they can only do so if they know what tools they have available, and that those tools can be relied upon. They set aside prep time; they have to know that they won't need to spend more than X hours per week to prep for this. If they can't predict how much time it will take to use a tool each week, they won't be able to use it. Tools need to be consistent from day to day, but also from year to year. Will they need to relearn a new toolset next year? She relayed a story about choosing the reading assessment tool the first grade team will use this school year. Should they use the same assessment program used in previous year even if there are missing books in the current set? Or should they switch to a different assessment program. It took them only 20 minutes total to make a decision. They based their decision on the consistency factor, affordability, and immediate response by customer service to their query which helped them solve the problem of having an incomplete assessment kit. The final selection was the same program that was being used in other grade levels, and the same program that was previously used. The takeaway I got from this story is that sometimes it isn't the design of the tool itself that makes it better for the classroom - sometimes its the deployability, and a big condition of that deployability is how it fits into the things that other teachers are doing and the other tools the same teacher will be using. Things beyond our control. (And usually beyond theirs.) We have to remember that Sugar will be one of many tools going into a classroom; teachers aren't just going to be deploying Sugar to their kids, they're also going to be deploying this math book, or that reading set, this Spanish programme, that alphabet chart, this counting-blocks set, this easel... And the support experience needs to be consistent. As explained above, teachers need to know that no matter what their problem is, if they spend 2 minutes reporting it at this location, it will be fixed N days later. And as soon as they've spent 2 minutes reporting it, they need immediate feedback and reassurance that yes, it's going to be fixed N days later; you were heard. It's not a fear of learning new things. It's being smart about wanting to know what returns on investment you can expect. It's silly to not know and limit how much it will cost (in terms of time) to get an unknown return on a potentially infinite investment. Consistency is a key design value. The reason teachers will choose not to use Sugar
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
Mel Chua wrote: Friendly. Is there a one-stop shop I can go to where my problems will be fixed immediately? ... Consistent. ... And the support experience needs to be consistent. As explained above, teachers need to know that no matter what their problem is, if they spend 2 minutes reporting it at this location, it will be fixed N days later. And as soon as they've spent 2 minutes reporting it, they need immediate feedback and reassurance that yes, it's going to be fixed N days later; you were heard. These two things sound pretty much the same to me. They also sound absolutely impossible, taken strictly. Taking a more relaxed interpretation, you seem to be describing, in effect, a full-time professional support staff. In the first world, such staff are not uncommon. The public high school I attended maintains both an in-house sysadmin team and a standing contract with Sony for advanced admin work on the special Sony-built multimedia clusters. If a school can afford that, then it's great, and that school could probably also afford a similar support contract for a Sugar deployment. No one is advertising such contracts at the moment, but there seem to be several companies keeping an eye on that market. In OLPC-land, there are many such professionals. For example, there is a full-time repair shop in Birmingham, AL devoted to fixing up children's broken XOs. We can try to encourage these sorts of services to spring up around SoaS as well, but it's important to remember that the students for whom we are most concerned do not live in school districts that can afford professional services. I don't think we will ever arrive at a situation where teachers in poor schools can expect any real assistance with Sugar, or any other computer system. Therefore, I think the most important thing we can do, on this front, is to devise deployment mechanisms that will degrade gracefully when operated by inexpert users in challenging environments. SoaS attempts this, with easy re-imaging of nonfunctioning sticks and no reliance on school infrastructure. There is certainly much more left to do. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
So you probably disagreed with my statement that SoaS is not about installing user files to a hard drive. Or do you mean having the Base OS on the drive, but the user files/activities directory on a stick? My use case does not require the user's environment to be portable. At least for now. However, if this experiment goes well and we can build on it, perhaps we'll do things differently. So, I was not disagreeing; just reflecting on the local conditions. Given the wide range of school schedules world wide, I'm not sure if it is reasonable to try to synchronize release schedules with any particular schedule. I'm willing to be educated if there is in fact Again, I'm just stating a preference based on my situation. Even if it would be the best thing for me, I realize that it's not necessarily the best thing for everyone else. It also seems like there is a desire among core Sugar developers to do releases more often then this as well as a desire to synchronize with Fedora's six month schedule. On the other hand, It seems like what As a developer I try to keep my computers up to date with the latest software. (The last year was painful because I was stubborn about KDE4. 4.3 is the charmed one!). As a tech support though, I much prefer stability over change and bug fixes over new features. Whatever release schedule is decided upon by SugarLabs, my own schedule is already clear: I change during the summer and I stick to that version for the entire school year. At least. Schools are no different from businesses in that way, and just like businesses would prefer something with long term support rather than something that changes every six months. It may very well be that I can adjust to any change but that people around me do not want to. It's been known to happen. Sooner or later, you're going to get that kind of demand. -- Philippe -- The trouble with common sense is that it is so uncommon. Anonymous ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
2009/9/15 Philippe Clérié phili...@gcal.net: So you probably disagreed with my statement that SoaS is not about installing user files to a hard drive. Or do you mean having the Base OS on the drive, but the user files/activities directory on a stick? My use case does not require the user's environment to be portable. At least for now. However, if this experiment goes well and we can build on it, perhaps we'll do things differently. So, I was not disagreeing; just reflecting on the local conditions. Given the wide range of school schedules world wide, I'm not sure if it is reasonable to try to synchronize release schedules with any particular schedule. I'm willing to be educated if there is in fact Again, I'm just stating a preference based on my situation. Even if it would be the best thing for me, I realize that it's not necessarily the best thing for everyone else. It also seems like there is a desire among core Sugar developers to do releases more often then this as well as a desire to synchronize with Fedora's six month schedule. On the other hand, It seems like what As a developer I try to keep my computers up to date with the latest software. (The last year was painful because I was stubborn about KDE4. 4.3 is the charmed one!). As a tech support though, I much prefer stability over change and bug fixes over new features. Whatever release schedule is decided upon by SugarLabs, my own schedule is already clear: I change during the summer and I stick to that version for the entire school year. At least. Schools are no different from businesses in that way, and just like businesses would prefer something with long term support rather than something that changes every six months. It may very well be that I can adjust to any change but that people around me do not want to. It's been known to happen. Sooner or later, you're going to get that kind of demand. Yes, we may move in the future to do LTS releases, but before we get there maybe we should have first people who can actually support older releases. What we can do is alternating less exciting releases with bleeding edge ones. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick (was [Sugar-Devel] The Future of Sugar on a Stick)
On Mon, Sep 14, 2009 at 13:56, Walter Bender walter.ben...@gmail.comwrote: To Martin's point, how about the routine use of a filterable tag, [SoaS] , in the Subject to messages appropriately routed to either IAEP or Devel or both? I just created a Sugar on a Stick topic on Sugar-Devel's mailman, which matches the pattern [SoaS] in the subject of a message. -- Luke Faraone http://luke.faraone.cc ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick (was [Sugar-Devel] The Future of Sugar on a Stick)
On Mon, Sep 14, 2009 at 02:04:28PM -0400, Luke Faraone wrote: On Mon, Sep 14, 2009 at 13:56, Walter Bender walter.ben...@gmail.comwrote: To Martin's point, how about the routine use of a filterable tag, [SoaS] , in the Subject to messages appropriately routed to either IAEP or Devel or both? I just created a Sugar on a Stick topic on Sugar-Devel's mailman, which matches the pattern [SoaS] in the subject of a message. If you go down that path, then perhaps it makes sense to merge -devel and -iaep lists and do the same for them: It seems to me that most posts are cross-posted anyway. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick (was [Sugar-Devel] The Future of Sugar on a Stick)
b On Mon, Sep 14, 2009 at 2:04 PM, Luke Faraone l...@faraone.cc wrote: On Mon, Sep 14, 2009 at 13:56, Walter Bender walter.ben...@gmail.com wrote: To Martin's point, how about the routine use of a filterable tag, [SoaS] , in the Subject to messages appropriately routed to either IAEP or Devel or both? I just created a Sugar on a Stick topic on Sugar-Devel's mailman, which matches the pattern [SoaS] in the subject of a message. If we are going to go down this route (which I still believe is inferior to having separate mailing lists) then you need to: Modify this page to list all of the current sugar-devel topics (we are now up to four): http://lists.sugarlabs.org/listinfo/sugar-devel as well as letting people know there and in the welcome to the list email how they can modify their subscription options at: http://lists.sugarlabs.org/options/sugar-devel so they only get messages on the topics that are relevant to them. Upon rereading Walter's note, I guess you need this for IAEP as well. While we are at it, can we get [GPA] topics as well, since we can't have a GPA mailing list. Bill Bogstad ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick (was [Sugar-Devel] The Future of Sugar on a Stick)
On Mon, Sep 14, 2009 at 7:04 PM, Luke Faraone l...@faraone.cc wrote: On Mon, Sep 14, 2009 at 13:56, Walter Bender walter.ben...@gmail.com wrote: To Martin's point, how about the routine use of a filterable tag, [SoaS] , in the Subject to messages appropriately routed to either IAEP or Devel or both? I just created a Sugar on a Stick topic on Sugar-Devel's mailman, which matches the pattern [SoaS] in the subject of a message. I would prefer to filter messages client side rather than having something enforced on me. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick (was [Sugar-Devel] The Future of Sugar on a Stick)
On Mon, Sep 14, 2009 at 16:05, Peter Robinson pbrobin...@gmail.com wrote: I would prefer to filter messages client side rather than having something enforced on me. Er, it's not *enforced*, as if you don't specify any topic you'll get all mail sent to the list. Please see the help text Kevin posted earlier in the thread. -- Luke Faraone http://luke.faraone.cc ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
