Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable
On Sun, Aug 08, 2010 at 06:02:58PM -0500, Mikus Grinbergs wrote: > In my opinion, developers of a product ought to be interested in > learning about shortcomings perceived in that product by users. Certainly interested. But not willing to prance about looking for problems when some very neatly defined problems are already logged waiting for fixing. Also not willing to go and interview every user; this does not scale. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable
On 9 August 2010 11:02, Mikus Grinbergs wrote: > > in general I think it's entirely appropriate to expect > > that people asking for help do so via the correct channels > > I believe that "asking for help" should not be the only supported > motivation for contacting developers. > Not at all, but it's a significant one. > In my opinion, developers of a product ought to be interested in > learning about shortcomings perceived in that product by users. > Looking into the original case - we had people on a public forum[1] expressing frustration that yum fails to work among other things. I hope this doesn't come across the wrong way - but are G1G1 laptop owners considered the target market? If a user installs Skype on an XO-1, only to find that it kills the sound, then I think it's okay for OLPC to abstain from taking responsibility. Fora such as olpcnews.com attracts very motivated individuals who experiment. That's great, but once they leave the realm of the product, peer support takes over. In practice, it seems that genuine issues from these comments do find their way to the surface, albeit in roundabout way. OLPC & Sugar Labs are now aware that yum doesn't seem to work. > Are "the correct channels" any different than blinders ? > > mikus > I'm not sure I understand what you mean by blinders. Do you mean blinkers? [edit: Wikipedia says yes] In many ways that's true, but the metaphor doesn't transfer exactly. Each channel (Trac, wiki, mailing list, local user group) deals with a different type of problem. They e simply to block unintended knowledge. However, it's likely that some people will be put off - which means that they become fairly blunt filters. Where the metaphor does fit is using a system to create focus. It's important to recognise that OLPC & Sugar Labs have very constrained development resources. Therefore, systems that reduce load on developers increases time on development. Tim [1] http://www.olpcnews.com/forum/index.php?topic=4867 ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable
On Mon, Aug 9, 2010 at 4:17 PM, Neil Graham wrote: > And yet, Developers on this list [olpc-devel] have complained when > people have done that, because this is not the place for it. Of course, > there isn't any other place for it. Don't take every complaint seriously ;-) > I really don't want to get combative here. This may come off as "You > guys all suck" but what I want is for things to improve. We all do. But we are damned swamped with things, and we do a ton with the community. You might not see it right now but we do. ... > but a friend of mine who attended PyCon came back and said he was amazed > with just how many people he met who felt burned by OLPC. Having been an external volunteer first, I can attest that it is hard to contribute to OLPC. A lot of that is because OLPC has chosen to do hard things. OLPC requires a lot of time investment. All the other open proects I know that have similarly hard goals are known to burn people out. Don't know if there's a fix for that "overall" problem :-/ Are there specific issues you are hoping for support with, what are they? cheers, 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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable (was: Re: OLPC 10.1.2 Release Candidate 1)
On Sun, Aug 8, 2010 at 5:09 PM, Christoph Derndorfer wrote: > I know I'm repeating myself here but I find the attitude expressed in these > instructions and particularly point 3 troublesome and a continued source of > frustration for me as well as other people I've talked to. Even more so I > think it's a very clear symptom of the much-discussed disconnect between > developers and end-users in the OLPC and Sugar Labs context. Not really. There is a lot of "glue people" that can help bridge the gap between teachers / nontechie deployers and developers. I am one of them. I am sure you are one too. Deployments need to have a (small) technical team that also fits this role. Such bridge people are needed to boil down end users' reports into something that looks like a usable bugreport. Being a bridge person, a translator between the two worlds is sometimes frustrating ("can't these people talk to eachother directly?") but the barriers are real. Rejoice in being able to do it (at least I do). And sure -- we need to get more hands (ears/eyes) into this role. It is essential social glue. cheers, 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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable
On Mon, Aug 9, 2010 at 12:46 AM, Neil Graham wrote: > Perhaps what is needed is a KDE to olpc's gnome in order to lift the > game of both. We do a ton of things in relationship with our 'community' (or perhaps our different 'communities'). For example, we engage in this thread with you. As with most projects, it's up to you to help, participate positively, or not. cheers, 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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable
On Sun, Aug 08, 2010 at 06:02:58PM -0500, Mikus Grinbergs wrote: > In my opinion, developers of a product ought to be interested in > learning about shortcomings perceived in that product by users. Certainly interested. But not willing to prance about looking for problems when some very neatly defined problems are already logged waiting for fixing. Also not willing to go and interview every user; this does not scale. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable
On 9 August 2010 11:02, Mikus Grinbergs wrote: > > in general I think it's entirely appropriate to expect > > that people asking for help do so via the correct channels > > I believe that "asking for help" should not be the only supported > motivation for contacting developers. > Not at all, but it's a significant one. > In my opinion, developers of a product ought to be interested in > learning about shortcomings perceived in that product by users. > Looking into the original case - we had people on a public forum[1] expressing frustration that yum fails to work among other things. I hope this doesn't come across the wrong way - but are G1G1 laptop owners considered the target market? If a user installs Skype on an XO-1, only to find that it kills the sound, then I think it's okay for OLPC to abstain from taking responsibility. Fora such as olpcnews.com attracts very motivated individuals who experiment. That's great, but once they leave the realm of the product, peer support takes over. In practice, it seems that genuine issues from these comments do find their way to the surface, albeit in roundabout way. OLPC & Sugar Labs are now aware that yum doesn't seem to work. > Are "the correct channels" any different than blinders ? > > mikus > I'm not sure I understand what you mean by blinders. Do you mean blinkers? [edit: Wikipedia says yes] In many ways that's true, but the metaphor doesn't transfer exactly. Each channel (Trac, wiki, mailing list, local user group) deals with a different type of problem. They e simply to block unintended knowledge. However, it's likely that some people will be put off - which means that they become fairly blunt filters. Where the metaphor does fit is using a system to create focus. It's important to recognise that OLPC & Sugar Labs have very constrained development resources. Therefore, systems that reduce load on developers increases time on development. Tim [1] http://www.olpcnews.com/forum/index.php?topic=4867 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable
> in general I think it's entirely appropriate to expect > that people asking for help do so via the correct channels I believe that "asking for help" should not be the only supported motivation for contacting developers. In my opinion, developers of a product ought to be interested in learning about shortcomings perceived in that product by users. Are "the correct channels" any different than blinders ? mikus ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable (was: Re: OLPC 10.1.2 Release Candidate 1)
On 9 August 2010 09:09, Christoph Derndorfer wrote: > On Sun, Aug 8, 2010 at 3:56 PM, Ed McNierney wrote: > >> Instructions: >> >> 1. Report bugs at http://dev.laptop.org/newticket - if necessary, >> register first at http://dev.laptop.org/register (as mavrothal kindly >> points out) >> 2. If you have interesting experiences or user information to contribute, >> please do so at http://wiki.laptop.org >> 3. If you're unwilling to perform steps 1 and/or 2 as appropriate, please >> don't expect the bug to be fixed, or for anyone else to even know about it. >> > > I know I'm repeating myself here but I find the attitude expressed in these > instructions and particularly point 3 troublesome and a continued source of > frustration for me as well as other people I've talked to. Even more so I > think it's a very clear symptom of the much-discussed disconnect between > developers and end-users in the OLPC and Sugar Labs context. > > The core here is that software developers seem very reluctant to step out > of their own comfort zone when it comes to processes and tools (a.k.a. point > 3 a.k.a. "my way or the highway") yet consistently expect teachers and other > XO and Sugar users to do exactly that. > I'm not sure of the wider context here, but in general I think it's entirely appropriate to expect that people asking for help do so via the correct channels. It's also appropriate for OLPC & Sugar to set realistic expectations. Placing the burden on the user may be the only way to understand what's going wrong with the software. That said, the OLPC/Sugar communities should be very good at guiding new contributors to those channels. Perhaps OLPC/Sugar could create a super simple web form for problem submissions. They would then be triaged (by support gang?) and sent to the correct ticker. That way, new contributions only have a single channel for everything. > This leads to the current situation in which crucial information and > feedback from these users does not make it back to developers and the > broader community. Therefore rather than working on things that users need > or need to work reliably (e.g. the Journal) resources are spent elsewhere. > This is not the only reasons why the development of pieces of Sugar moves very slowly. The datastore is a complex piece of software engineering. I have no idea how it works and don't think I'll ever able to understand it without someone next to me explaining its operation. The real problem for me, even if I wanted to help with the Journal, is that there is nearly no code documentation through Sugar's core. I find it very difficult to justify spending a few hours learning how a module operates when I want to fix a bug. Yet, this is the situation I face every time. An associated problem for me is that I don't know if my code will break things. AFAIK , there are no unit tests in Sugar's code base. Sugar is actually quite hard to test. Secondly, many of the functions & methods are not designed with (unit) testing in mind, meaning it's hard to retrospectively create tests for methods. Testing side effects is annoying. Even if unit testing was integrated into Sugar's development, it's really tough to set up development & test environments. sugar-jhbuild has never built correctly for me. Looking through compiler errors trying to identify what's wrong makes me feel like an idiot. The reason I don't look into the hard problems is not that I don't know they exist. It's that they're hard to even start looking into. Tim ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable (was: Re: OLPC 10.1.2 Release Candidate 1)
On Sun, Aug 8, 2010 at 5:09 PM, Christoph Derndorfer wrote: > On Sun, Aug 8, 2010 at 3:56 PM, Ed McNierney wrote: >> >> Instructions: >> >> 1. Report bugs at http://dev.laptop.org/newticket - if necessary, register >> first at http://dev.laptop.org/register (as mavrothal kindly points out) >> 2. If you have interesting experiences or user information to contribute, >> please do so at http://wiki.laptop.org >> 3. If you're unwilling to perform steps 1 and/or 2 as appropriate, please >> don't expect the bug to be fixed, or for anyone else to even know about it. > > I know I'm repeating myself here but I find the attitude expressed in these > instructions and particularly point 3 troublesome and a continued source of > frustration for me as well as other people I've talked to. Even more so I > think it's a very clear symptom of the much-discussed disconnect between > developers and end-users in the OLPC and Sugar Labs context. > > The core here is that software developers seem very reluctant to step out of > their own comfort zone when it comes to processes and tools (a.k.a. point 3 > a.k.a. "my way or the highway") yet consistently expect teachers and other > XO and Sugar users to do exactly that. What was the context for Ed's post? And who was his intended audience? Certainly not the end user. In .uy we have discussed various mechanisms for bug reporting by children and teachers. The current plan of record is to use some sort of web form where the bugs are aggregated by a technical liaison. The liaison might then be trained in filing the occasional ticket on Trac. As with any software (and hardware) project, different people in the support hierarchy utilize different tools. -walter > This leads to the current situation in which crucial information and > feedback from these users does not make it back to developers and the > broader community. Therefore rather than working on things that users need > or need to work reliably (e.g. the Journal) resources are spent elsewhere. > > But that's all just basically a recap of the IRC discussion on #sugar > earlier in the week and many hours of discussions with Bernie and others in > Paraguay over the past 2 weeks. > > Now at this point I'd normally stop but seeing that I've been increasingly > frustrated about this and have subsequently complained a lot about it I'll > get off my ass and try something to improve the situation a bit. > > Over the next 6 weeks (can't make promises beyond that since university and > my job will then start again) I plan to: > > (a) Contact people at deployments asking for their input as to whether they > see a need for a closer feedback-loop between deployments and development > (because maybe I'm seeing issues when in fact there are none). For this I'll > rely on the people I know plus the contacts listed at > http://wiki.sugarlabs.org/go/Deployment_Team/Places for starters but please > send along any suggestions on who else to get in touch with. > (b) If it turns out to be a need then ask for input as to how these needs > could be best communicated so we can figure out an appropriate process. > (c) Try to schedule some sort of meeting with several deployments, possibly > as a continuation of the Sugar Labs deployment meetings on IRC or via a > Skype call or something. In my mind the focus here should be input into what > deployments would like to see development focus (more) on. > (d) Compile all the resulting input into a readable format and distribute it > where seen appropriate. > > Things I most likely won't do as part of these efforts include (but aren't > necessarily limited to) setting up new mailman-lists, creating a new > category on w.l.o or w.s.o and following wiki talk-pages, asking for a trac > instance, learning to use git send-email, switching to Mutt, booting into > Ubuntu instead of Windows 7, etc. ;-) > > As always, let me know what you think. > > Cheers, > Christoph > > -- > Christoph Derndorfer > co-editor, olpcnews > url: www.olpcnews.com > e-mail: christ...@olpcnews.com > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel