Re: [IAEP] [Sugar-devel] Deployment feedback braindump
Hi, some thoughts follow. Please keep in mind that these are just my personal opinions and that not everybody at Sugar Labs share the same idea of what SLs is or should be. On Sun, Aug 9, 2009 at 19:41, Daniel Drake wrote: > Hi, > > In response to the thread I started recently about feedback from > deployments, I've been thinking a lot about specific changes/features > that would be a big help for deployments. > > And even though it only takes 10 minutes in a classroom to see some > real potential areas for improvement, actually I am finding the task > of selecting a few important features/bugs/changes very difficult, and > I keep coming back to various broad questions and loose ideas about > Sugar's direction, goals, and SugarLabs' roles. It's great that you are sharing your thoughts on this, hope others will do the same. I'm cc'ing IAEP because this isn't really technical. > So I'm afraid that I'm creating another vague, broad and fluffy > discussion without any real immediate technically actionable items, > but I'm going to try and put my thoughts into writing anyway. > Suggestions on how to make some of these ideas actionable would be > appreciated. I fully understand that nobody can really define Sugar's > direction at the moment since it's all volunteer time, but hopefully > we can at least get some objective things written down which will > possibly feed the motivation of our valued hackers. And not only hackers, but most of Sugar Labs. Those already working on a deployment have probably little energy left to consider other deployments' needs, but all the rest of the community will be sensible to the needs of the deployments that care to communicate their needs. > I'll start with roles. Sugar was born inside the belly of OLPC, and > SugarLabs was born out of OLPC, effectively taking some roles of OLPC > and further opening them to a community. So, in terms of roles, you > might look at this as OLPC being top of the food chain (I'm referring > to the times when OLPC had a substantially larger technical team), > with SugarLabs below doing some specific subset of OLPC's earlier work > (i.e. developing the UI), and finally deployments below being the > consumers. I'm not sure I agree with that. I see Sugar Labs as a _place_ where everybody interested in improving learning with Sugar can meet, communicate and work together. As far as I know OLPC has never aimed to be a place, but rather an agent. Who may be taking responsibilities from OLPC are other agents such as OLE Nepal and individual volunteers, who happen to use Sugar Labs to work together. > But actually I think it makes sense for this model to be considered > differently, as follows: SugarLabs is the top of the chain, it is the > upstream that generates the core user experience. One step down, OLPC > as an implementation specialist (again referring to the time when the > development team was more substantial) takes Sugar from upstream, > makes some small customizations to fit the OLPC mission, and fills in > some big gaps of OS development and support, deployability and > scalability, distribution, hardware work and software to support such > hardware, user support, etc. Then the deployments feed directly from > OLPC, not sugarlabs. In this model, OLPC performs a huge chunk of > support for sugar's users. This makes sense, we are also seeing several other organizations playing that role, but it's also true as you point below that some SLs members prefer to carry these activities as part of Sugar Labs rather than on their own organizations. I hope that this is temporary and that as their deployment activities scale up we'll see new organizations getting formed and their relationship with Sugar Labs formalized as local labs. > I think this model was working reasonably well (and was improving over > time) but the middle layer (OLPC) has now changed to the point where > it is not performing many of the roles mentioned above, or at least > not in much capacity. So who can take over this work? It is certainly > very important. My gut feeling is that SugarLabs should - but that > really is only because (1) a number of the OLPC people who would be > involved in the above roles are no longer OLPC people, but they are > still sugarlabs contributors, and (2) there are no other good > candidate parties that I can think of, so I naturally have desires > that the one that I do know of pick up the work ;) Don't think we should see in Sugar Labs more than there really is. It's true that we have a rather broad mission, so most of what can be done with Sugar has a place in SLs, but that broadness of mission also means that we (as a single organization) don't have enough focus to solve every issue that real users find. The broadness of our mission means that everybody who wants to use Sugar for learning has a place in SLs, but that doesn't mean that SLs itself is going to take care of everything. Rather, it means that people who want to use Sugar in
Re: [IAEP] [Sugar-devel] Deployment feedback braindump
Hi Tomeu,
2009/8/10 Tomeu Vizoso :
> Hi,
>
> some thoughts follow. Please keep in mind that these are just my
> personal opinions and that not everybody at Sugar Labs share the same
> idea of what SLs is or should be.
Thanks for the response.
What you are saying makes sense -- it is indeed a nice idea to keep
SugarLabs as more of a loose structure, as a place for collaboration
on anything that might further the general mission.
It is a sensible idea to keep SugarLabs away from doing too much work
on the OS building and deployment implementing side of things, because
as you point out, even when you exclude those broad topics there is
still a lack of resources on the bits that remain.
That said, in a way, the "gap" that we're discussing is in some ways
more important than any of the Sugar features currently being worked
on, because the large majority of sugar users are currently a long way
away from even having access to the features that were finished 6
months ago. Difficult.
I disagree about local labs being key to filling the gap. While a nice
idea, I think it is necessary for there to be a central and
location-independent deployment-focused upstream, otherwise there will
be a lack of coordination accompanied by lots of duplication of work.
Local labs need to feed into something bigger, which doesn't currently
exist, although it could probably sit under the realm of sugarlabs if
the right people were to step up.
Also, when talking of scale, I am a little wary of local community
efforts because they have previously proven disruptive to deployments.
The sad reality is that you absolutely require more of a NGO or
business setup to be working with the relevant authorities. And when
this happens, the community efforts automatically become a bit
distanced. For example in many of these places, the "official"
organisation receives permission from the government for their staff
to enter government schools - but only their staff (not community
volunteers).
You mention lack of involvement and feedback from deployments -- why
do you think this is?
Here are some of my thoughts:
- The majority people we're working with are alien to the idea that
they might be able to talk to the people who are writing the software
that they are using. Since when has anyone been able to do that? Us
open source people are still the oddities in the world.
- People are afraid or mythed by the idea of this stuff being public
and global ("why would I want my feedback to be public?"), and are
confused/challenged by mailing lists.
- The people most able to give the kind of feedback you are looking
for are the teachers, who are probably even more distanced from these
ideas. Many will lack connectivity and english language skills.
- Many people who support the project with technical skills (e.g.
Linux) come from purely academic backgrounds which means they
understand the technical stuff well, but have little interest,
experience (and sometimes ability) to become good community members.
To put it plainly: in my opinion, wishing for substantially more
involvement from deployments is not realistic. SugarLabs would benefit
from being proactive here, especially by using the telephone rather
than email to contact deployments, but this is of course subject to
the "where are the resources?" question. Hopefully over time a
proactive approach from our side would likewise encourage a proactive
approach to communication from the deployments, but I suspect we'll
have to be patient. and yes, this makes your job pretty difficult.
> On Sun, Aug 9, 2009 at 19:41, Daniel Drake wrote:
>> At least from what I have seen, this kind of clarity seems to be
>> missing from discussions that define the Sugar platform nowadays, as
>> well as in the code that is flowing through the system. Does SugarLabs
>> still have a high degree of interest in bigger-than-you-can-believe
>> deployments in remote and really difficult parts of the world on
>> low-spec hardware, or are we moving towards looking at occasional
>> 30-student deployments on powerful computers in schools along the
>> Charles? Or are we trying to do both?
>> Are we still focusing on 6-12 year olds or has that changed?
>
> How do you expect that the SLs volunteers know what OLPC deployments
> need if they don't voice their needs? If you look at the Sugar commit
> logs, you will see that almost all commits are from someone sitting in
> a room somewhere in Europe, working on their free time. By which kind
> of epiphany do you expect them to know what's best for OLPC
> deployments?
I think you misunderstood my position here. I am personally having
trouble trying to formulate this kind of feedback because I no longer
know what is important to Sugar. Maybe it is a personal
misunderstanding, but after seeing some recent discussions and
features I feel that some of the core goals that formed the project in
its earlier stages have been lost. I am glad to see your response
which suggests that these things are st
Re: [IAEP] [Sugar-devel] Deployment feedback braindump
Daniel Drake wrote: > What you are saying makes sense -- it is indeed a nice idea to keep > SugarLabs as more of a loose structure, as a place for collaboration > on anything that might further the general mission. > > It is a sensible idea to keep SugarLabs away from doing too much work > on the OS building and deployment implementing side of things, because > as you point out, even when you exclude those broad topics there is > still a lack of resources on the bits that remain. > That said, in a way, the "gap" that we're discussing is in some ways > more important than any of the Sugar features currently being worked > on, because the large majority of sugar users are currently a long way > away from even having access to the features that were finished 6 > months ago. Difficult. > > I disagree about local labs being key to filling the gap. While a nice > idea, I think it is necessary for there to be a central and > location-independent deployment-focused upstream, otherwise there will > be a lack of coordination accompanied by lots of duplication of work. I agree... and I think the only way this will happen is for someone to start a company. You would be an ideal person to do such a thing. Consider the Gnome Foundation. The organization is composed principally of software engineers, working on a technical problems. They do not attempt to manage deployments or provide end-user support. They do not produce operating systems, apart from a few Live CDs for testing and validation purposes. They employed no one for many years, and now employ only one person, purely for administrative duties. Gnome is widely deployed, and supported, but this is done by organizations like Debian, Canonical, Slackware, and Red Hat. These deployers have both the incentive and the ability to respond quickly to user demands, by customizing their Gnome installation. They also communicate with Gnome upstream, getting their modifications into mainline and pushing for development that addresses their users' needs. In fact, most of the Gnome developers are actually employed by deployers, like Novell, and the Gnome Foundation is merely the place where all the deployers' engineers come to work together. Sugar Labs is explicitly modeled on the Gnome Foundation. I agree that there is a gap between Sugar Labs and deployment, but this is best addressed by a similar two-layer model. OLPC is part of that second layer, and so is Solution Grove, but we certainly need more. As for "local labs"... the term seems to have been used for many things. Some non-profit deployment organizations might request recognition as a "local lab" if they think it helps their marketing, and Sugar labs would likely be happy to confer the title upon them. signature.asc Description: OpenPGP digital signature ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Deployment feedback braindump
Hi Daniel., excellent post - skipping to the "let's make it deployable" part, I have to say I agree with all you say. - Some comments below On Sun, Aug 9, 2009 at 1:41 PM, Daniel Drake wrote: > Secondly, this just won't work for deployments in general. Deployments > are really difficult. You don't have enough people, so everyone is Yes. I am looking now at all the barriers to a deployment team, and to teachers in a crowded classroom. My mantra going forward is going to be: - am I knocking down a barrier to deploymeny? - am I simplifying teacher's life in the classroom? - am I giving an average 6~8 year-old a better learning opportunity? - am I significantly cutting the learning curve? If it's not in very concrete terms on that list, then skip to the next task :-) > In many of these places it is really difficult to find > people with the required computing skillsets, and even if they exist > they aren't likely to accept the piddly salary offered by your > cash-strapped NGO or govt organisation. Yes. > *really* challenging them (and sometimes, excluding them). Most of thetime - excluding them. ... > Now moving onto some things more directly related to deployment > experience. As I stated in my questions above, I'm not sure, but I'm > really hoping that sugar is just as dedicated as it always was to > provide a really really simple UI for 6 year old children. Everything > is so much harder in a classroom, and every small problem encountered > causes significant disruption. Yes. Even if 1 XO doesn't work or one child gets "lost" in a process, it distracts ~4 users, because humans are social, and the chatter of "won't work for me" stops progress. It only takes around 5% of users having minor trouble to get 50% of the class distracted. And at that point you have to give up on the XOs and turn to the blackboard. Every little obstacle counts. > How about the first boot experience - typing in your name and choosing > colours? (...) Sugar 0.84 makes that into every activity... it won't save unless you give it a name for the document. Can we disable that? Maybe not in the official SoaS but can there be a knob somewhere to revert it? > We've all heard the problems of children deleting activities by now. > I've also seen kids click the "disable wireless" box and then wonder > why they can't get online. I think that this highlights 2 things -- That's been added for G1G1 and power user / developer userbase - > Simplifying the user experience is *key* -- sugar has already taken > many leaps in this area, let's keep this as a high priority, and make > sure that this is communicated. Can I propose Daniel for president? ... > Sugar is obviously geared to constructionist learning which is > generally carried out differently from normal learning using books, Actually, having books is crucial for social constructionism too -- read it as much as your curioisity drives you to, revisit it as often as you like. And then do the social things you'll naturally do with what you discovered... In short, listen to the man. m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Deployment feedback braindump
FWIW, It sounds like you both are pretty much in sync and are
providing two much needed voices. The challenge that you both are
clearly articulating is that of seemingly unlimited needs and limited
resources.
The only thing I would like to add is, "Please note the tone of this
discussion with compared to similar discussion a year ago." This
discussion we can build on!
I would encourage Tomeu not to take it personally. _Everybody_ all
ways wants more from their engineer's. I would encourage Daniel to
start breaking down the deployment needs in to items which we can
prioritize and implement.
david
On Mon, Aug 10, 2009 at 11:53 AM, Daniel Drake wrote:
> Hi Tomeu,
>
> 2009/8/10 Tomeu Vizoso :
>> Hi,
>>
>> some thoughts follow. Please keep in mind that these are just my
>> personal opinions and that not everybody at Sugar Labs share the same
>> idea of what SLs is or should be.
>
> Thanks for the response.
>
>
> What you are saying makes sense -- it is indeed a nice idea to keep
> SugarLabs as more of a loose structure, as a place for collaboration
> on anything that might further the general mission.
>
> It is a sensible idea to keep SugarLabs away from doing too much work
> on the OS building and deployment implementing side of things, because
> as you point out, even when you exclude those broad topics there is
> still a lack of resources on the bits that remain.
> That said, in a way, the "gap" that we're discussing is in some ways
> more important than any of the Sugar features currently being worked
> on, because the large majority of sugar users are currently a long way
> away from even having access to the features that were finished 6
> months ago. Difficult.
>
> I disagree about local labs being key to filling the gap. While a nice
> idea, I think it is necessary for there to be a central and
> location-independent deployment-focused upstream, otherwise there will
> be a lack of coordination accompanied by lots of duplication of work.
> Local labs need to feed into something bigger, which doesn't currently
> exist, although it could probably sit under the realm of sugarlabs if
> the right people were to step up.
>
> Also, when talking of scale, I am a little wary of local community
> efforts because they have previously proven disruptive to deployments.
> The sad reality is that you absolutely require more of a NGO or
> business setup to be working with the relevant authorities. And when
> this happens, the community efforts automatically become a bit
> distanced. For example in many of these places, the "official"
> organisation receives permission from the government for their staff
> to enter government schools - but only their staff (not community
> volunteers).
>
> You mention lack of involvement and feedback from deployments -- why
> do you think this is?
> Here are some of my thoughts:
> - The majority people we're working with are alien to the idea that
> they might be able to talk to the people who are writing the software
> that they are using. Since when has anyone been able to do that? Us
> open source people are still the oddities in the world.
> - People are afraid or mythed by the idea of this stuff being public
> and global ("why would I want my feedback to be public?"), and are
> confused/challenged by mailing lists.
> - The people most able to give the kind of feedback you are looking
> for are the teachers, who are probably even more distanced from these
> ideas. Many will lack connectivity and english language skills.
> - Many people who support the project with technical skills (e.g.
> Linux) come from purely academic backgrounds which means they
> understand the technical stuff well, but have little interest,
> experience (and sometimes ability) to become good community members.
>
> To put it plainly: in my opinion, wishing for substantially more
> involvement from deployments is not realistic. SugarLabs would benefit
> from being proactive here, especially by using the telephone rather
> than email to contact deployments, but this is of course subject to
> the "where are the resources?" question. Hopefully over time a
> proactive approach from our side would likewise encourage a proactive
> approach to communication from the deployments, but I suspect we'll
> have to be patient. and yes, this makes your job pretty difficult.
>
>> On Sun, Aug 9, 2009 at 19:41, Daniel Drake wrote:
>>> At least from what I have seen, this kind of clarity seems to be
>>> missing from discussions that define the Sugar platform nowadays, as
>>> well as in the code that is flowing through the system. Does SugarLabs
>>> still have a high degree of interest in bigger-than-you-can-believe
>>> deployments in remote and really difficult parts of the world on
>>> low-spec hardware, or are we moving towards looking at occasional
>>> 30-student deployments on powerful computers in schools along the
>>> Charles? Or are we trying to do both?
>>> Are we still focusing on 6-12 year olds or has that chang
Re: [IAEP] [Sugar-devel] Deployment feedback braindump
On Mon, Aug 10, 2009 at 5:27 PM, Benjamin M. Schwartz < bmsch...@fas.harvard.edu> wrote: > Daniel Drake wrote: > > What you are saying makes sense -- it is indeed a nice idea to keep > > SugarLabs as more of a loose structure, as a place for collaboration > > on anything that might further the general mission. > > > > It is a sensible idea to keep SugarLabs away from doing too much work > > on the OS building and deployment implementing side of things, because > > as you point out, even when you exclude those broad topics there is > > still a lack of resources on the bits that remain. > > That said, in a way, the "gap" that we're discussing is in some ways > > more important than any of the Sugar features currently being worked > > on, because the large majority of sugar users are currently a long way > > away from even having access to the features that were finished 6 > > months ago. Difficult. > > > > I disagree about local labs being key to filling the gap. While a nice > > idea, I think it is necessary for there to be a central and > > location-independent deployment-focused upstream, otherwise there will > > be a lack of coordination accompanied by lots of duplication of work. > > I agree... and I think the only way this will happen is for someone to > start a company. You would be an ideal person to do such a thing. > > Consider the Gnome Foundation. The organization is composed principally > of software engineers, working on a technical problems. They do not > attempt to manage deployments or provide end-user support. They do not > produce operating systems, apart from a few Live CDs for testing and > validation purposes. They employed no one for many years, and now employ > only one person, purely for administrative duties. > > Gnome is widely deployed, and supported, but this is done by organizations > like Debian, Canonical, Slackware, and Red Hat. These deployers have both > the incentive and the ability to respond quickly to user demands, by > customizing their Gnome installation. They also communicate with Gnome > upstream, getting their modifications into mainline and pushing for > development that addresses their users' needs. In fact, most of the Gnome > developers are actually employed by deployers, like Novell, and the Gnome > Foundation is merely the place where all the deployers' engineers come to > work together. > > Sugar Labs is explicitly modeled on the Gnome Foundation. I agree that > there is a gap between Sugar Labs and deployment, but this is best > addressed by a similar two-layer model. OLPC is part of that second > layer, and so is Solution Grove, but we certainly need more. > > As for "local labs"... the term seems to have been used for many things. > Some non-profit deployment organizations might request recognition as a > "local lab" if they think it helps their marketing, and Sugar labs would > likely be happy to confer the title upon them. > > > ___ > IAEP -- It's An Education Project (not a laptop project!) > IAEP@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/iaep > This comparison of roles between Sugarlabs and GNOME Foundation is helpful. It allows me to think about how efforts have been successful (and have failed) when it comes to distros like Ubuntu and companies that support the process (Canonical in this case). The Ubuntu side of things doesn't get to see much of say, what conspires between Canonical and Dell. This is a much needed discussion. cheers, Sameer -- Dr. Sameer Verma, Ph.D. Associate Professor of Information Systems San Francisco State University San Francisco CA 94132 USA http://verma.sfsu.edu/ http://opensource.sfsu.edu/ ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Deployment feedback braindump
On Mon, Aug 10, 2009 at 18:53, Daniel Drake wrote:
> Hi Tomeu,
>
> 2009/8/10 Tomeu Vizoso :
>> Hi,
>>
>> some thoughts follow. Please keep in mind that these are just my
>> personal opinions and that not everybody at Sugar Labs share the same
>> idea of what SLs is or should be.
>
> Thanks for the response.
>
>
> What you are saying makes sense -- it is indeed a nice idea to keep
> SugarLabs as more of a loose structure, as a place for collaboration
> on anything that might further the general mission.
>
> It is a sensible idea to keep SugarLabs away from doing too much work
> on the OS building and deployment implementing side of things, because
> as you point out, even when you exclude those broad topics there is
> still a lack of resources on the bits that remain.
There's also the benefits of having a clear upstream/downstream
separation. Having the same people working on both aspects without
clear processes gets very messy at medium term.
> That said, in a way, the "gap" that we're discussing is in some ways
> more important than any of the Sugar features currently being worked
> on, because the large majority of sugar users are currently a long way
> away from even having access to the features that were finished 6
> months ago. Difficult.
Agreed, though if we stop making new releases, other people might get
the message that Sugar is dead thus not worth of deploying, packaging,
etc. But I'm ok with slowing deployment of new features for now and
focusing on bugfixing, polishing, etc
> I disagree about local labs being key to filling the gap. While a nice
> idea, I think it is necessary for there to be a central and
> location-independent deployment-focused upstream, otherwise there will
> be a lack of coordination accompanied by lots of duplication of work.
> Local labs need to feed into something bigger, which doesn't currently
> exist, although it could probably sit under the realm of sugarlabs if
> the right people were to step up.
Well, such work would be certainly welcome to happen inside Sugar
Labs, even if carried by other organizations, local labs or not. I
would like to clarify that the term local lab might be misleading
here. There's nothing wrong in Solutions Grove being a local labs and
also becoming the global services provider of SoaS, for example.
Though I think it would be more likely that we would see a local lab
working in several countries in latin america, other giving services
in South East Asia, etc. similar to how companies divide the global
market. There are good reasons for that.
> Also, when talking of scale, I am a little wary of local community
> efforts because they have previously proven disruptive to deployments.
> The sad reality is that you absolutely require more of a NGO or
> business setup to be working with the relevant authorities. And when
> this happens, the community efforts automatically become a bit
> distanced. For example in many of these places, the "official"
> organisation receives permission from the government for their staff
> to enter government schools - but only their staff (not community
> volunteers).
Local labs don't need to be all community efforts, can be companies,
governmental organizations, etc. Whatever works best for them. With
such a broad mission, we won't be able to find a single organizational
structure that works everywhere.
> You mention lack of involvement and feedback from deployments -- why
> do you think this is?
> Here are some of my thoughts:
> - The majority people we're working with are alien to the idea that
> they might be able to talk to the people who are writing the software
> that they are using. Since when has anyone been able to do that? Us
> open source people are still the oddities in the world.
> - People are afraid or mythed by the idea of this stuff being public
> and global ("why would I want my feedback to be public?"), and are
> confused/challenged by mailing lists.
> - The people most able to give the kind of feedback you are looking
> for are the teachers, who are probably even more distanced from these
> ideas. Many will lack connectivity and english language skills.
> - Many people who support the project with technical skills (e.g.
> Linux) come from purely academic backgrounds which means they
> understand the technical stuff well, but have little interest,
> experience (and sometimes ability) to become good community members.
That matches pretty well my observations. We have a disruptive message
to pass regarding community participation, which is pretty much the
same problem that Fedora or any other global open source project
faces. Local entities (ambassadors, user groups, local labs?) play a
very big role there because it's very hard for me from Prague to
explain to someone in the Andes how we can work together. But if that
person goes to an event organized by her local university and
establishes personal relationships with other people working with
Sugar in her community, that's a very good
Re: [IAEP] [Sugar-devel] Deployment feedback braindump
On Mon, Aug 10, 2009 at 20:03, Martin Langhoff wrote: > Hi Daniel., > > excellent post - skipping to the "let's make it deployable" part, I > have to say I agree with all you say. - Some comments below > > On Sun, Aug 9, 2009 at 1:41 PM, Daniel Drake wrote: >> Secondly, this just won't work for deployments in general. Deployments >> are really difficult. You don't have enough people, so everyone is > > Yes. I am looking now at all the barriers to a deployment team, and to > teachers in a crowded classroom. My mantra going forward is going to > be: > > - am I knocking down a barrier to deploymeny? > - am I simplifying teacher's life in the classroom? > - am I giving an average 6~8 year-old a better learning opportunity? > - am I significantly cutting the learning curve? > > If it's not in very concrete terms on that list, then skip to the next task > :-) > >> In many of these places it is really difficult to find >> people with the required computing skillsets, and even if they exist >> they aren't likely to accept the piddly salary offered by your >> cash-strapped NGO or govt organisation. > > Yes. > >> *really* challenging them (and sometimes, excluding them). > > Most of thetime - excluding them. > > ... >> Now moving onto some things more directly related to deployment >> experience. As I stated in my questions above, I'm not sure, but I'm >> really hoping that sugar is just as dedicated as it always was to >> provide a really really simple UI for 6 year old children. Everything >> is so much harder in a classroom, and every small problem encountered >> causes significant disruption. > > Yes. Even if 1 XO doesn't work or one child gets "lost" in a process, > it distracts ~4 users, because humans are social, and the chatter of > "won't work for me" stops progress. It only takes around 5% of users > having minor trouble to get 50% of the class distracted. > > And at that point you have to give up on the XOs and turn to the blackboard. > > Every little obstacle counts. > >> How about the first boot experience - typing in your name and choosing >> colours? (...) > > Sugar 0.84 makes that into every activity... it won't save unless you > give it a name for the document. Just in case it isn't known, you don't really have to give a name, you can just click the Keep button or press the return key. > Can we disable that? Maybe not in the > official SoaS but can there be a knob somewhere to revert it? Entered a ticket about it: http://dev.sugarlabs.org/ticket/1156 If you think this is important for deployments and make the case clear, there's good chances someone will volunteer to write a patch. Thanks, Tomeu >> We've all heard the problems of children deleting activities by now. >> I've also seen kids click the "disable wireless" box and then wonder >> why they can't get online. I think that this highlights 2 things -- > > That's been added for G1G1 and power user / developer userbase - > >> Simplifying the user experience is *key* -- sugar has already taken >> many leaps in this area, let's keep this as a high priority, and make >> sure that this is communicated. > > Can I propose Daniel for president? > > ... > >> Sugar is obviously geared to constructionist learning which is >> generally carried out differently from normal learning using books, > > Actually, having books is crucial for social constructionism too -- > read it as much as your curioisity drives you to, revisit it as often > as you like. And then do the social things you'll naturally do with > what you discovered... > > In short, listen to the man. > > > > > m > -- > martin.langh...@gmail.com > mar...@laptop.org -- School Server Architect > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - http://wiki.laptop.org/go/User:Martinlanghoff > ___ > IAEP -- It's An Education Project (not a laptop project!) > IAEP@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/iaep > ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Deployment feedback braindump
Hi Ian, looks like your email was dropped from the mailing list, reposting and answering below. On Tue, Aug 11, 2009 at 02:05, Ian Thomson wrote: > Hi Tomeu, > > I hear your plea for feedback from educators. > > First an introduction. I am the Project Manager for OLPC deployments in > Oceania. I am an engineer, not an educator, but I have worked in the Pacific > Islands for many years introducing computers and the Internet. So far, we > have deployed almost 3,000 XOs in 5 countries, mostly in pilots. > We are now planning for large scale trials, but of course, funding is an > issue. Nice to hear from you, hope we can help somehow along the way. > I have been a member of the IAEP list for several months and I have to say I > find the list daunting (despite my 30 plus years of working in high tech). I > would not recommend any Pacific Island educator to join it. They are far too > new to the internet (and ICT in education) and they are very shy, even in > their own settings. > > IMHO, the list is for developers with an interest in education, not the other > way around. It is very techno centric and it is very western in its culture > (as it must be I suppose). If you seek feedback from developing country > educators, we must make an environment that they will be comfortable in > > I fact I see this as a major risk to Sugar. All the postings I see are from > deployments and experts in developed countries. I don't feel that I can > contribute much, so how would an ICT newbie find it? > > The only suggestion I can come up with is that we need facilitated local > groups of educators to have the required discussions and then the facilitator > can feed the input to IAEP or other places. Of course, the problem is time > and resources. I agree with you and this is the opinion I have heard most often around here. I even tried to setup a structure like that some months ago, but didn't had much success that time:, maybe it's time to try again? http://wiki.sugarlabs.org/go/Deployment_Team/Places Christoph Derndorfer suggested a week ago that we propose a questionnaire to the people we know that are using Sugar with children: http://lists.sugarlabs.org/archive/sugar-devel/2009-August/017621.html This could be a good next step to stablish closer links to our partners in the field. About the feasibility of educators themselves getting involved in the global community, I would like to note that this doesn't look as utopic to me as some months ago. In the olpc-sur mailing list we have worked to build a community with teachers from mainly Uruguay but also from Paraguay and Peru and we have had some degree of success. We have entered tickets in our bug tracker (http://dev.sugarlabs.org) at the teacher request, we have developed new activities in reply to needs expressed by teachers, teachers have kindly tested such activities in the classroom and provided useful feedback, we have asked for their opinion when planning new features, etc. http://lists.laptop.org/pipermail/olpc-sur/ We are not yet where we want to be because in most cases it's still Walter and me who interact directly with them and this isn't going to scale, but some members from Sugar Labs Colombia and Ceibal Jam's Gabriel Eirea have started to help passing their feedback to developers. But I think this shows that it's possible and we have now very useful feedback about how to further scale this process. But we need more people to join the effort. And also we need to expand the olpc-sur success to other areas where Sugar is in use. About deployers being too busy to participate in Sugar Labs, well, they are the ones to decide on what to spend their own time. But I doubt our software is a perfect match for their needs and we do have talented software engineers that are willing to make Sugar work better for them. But if they just pick whatever new software release that OLPC distributes, chances are it won't address those unmet needs. Glad to hear your feedback Ian, will appreciate your ideas about how Sugar Labs can be a better place for deployments to work, share and pool resources. Regards, Tomeu > Ian Thomson > RICS and OLPC Coordinator > Noumea > SPC > Phone +687 26 01 44 > > > -Original Message- > From: iaep-boun...@lists.sugarlabs.org > [mailto:iaep-boun...@lists.sugarlabs.org] On Behalf Of Tomeu Vizoso > Sent: Monday, August 10, 2009 10:39 PM > To: Daniel Drake > Cc: iaep; sugar-devel > Subject: Re: [IAEP] [Sugar-devel] Deployment feedback braindump > > Hi, > > some thoughts follow. Please keep in mind that these are just my > personal opinions and that not everybody at Sugar Labs share the same > idea of what SLs is or should be. > > On Sun, Aug 9, 2009 at 19:41, Daniel Drake wrote: >> Hi, >> >> In re
