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 christoph.derndor...@gmail.com 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Making OLPC / Sugar Labs more approachable (was: Re: OLPC 10.1.2 Release Candidate 1)
On Sun, Aug 8, 2010 at 3:56 PM, Ed McNierney e...@laptop.org 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. 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/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 christoph.derndor...@gmail.com wrote: On Sun, Aug 8, 2010 at 3:56 PM, Ed McNierney e...@laptop.org 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-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/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 christoph.derndor...@gmail.com wrote: On Sun, Aug 8, 2010 at 3:56 PM, Ed McNierney e...@laptop.org 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Making OLPC / Sugar Labs more approachable (was: Re: OLPC 10.1.2 Release Candidate 1)
Christoph - (you're talking about OLPC and SugarLabs, of course, but I'm only responding from an OLPC perspective) There's a difference between approachable and findable. Every member of the OLPC technical staff is on the de...@laptop.org mailing list, and we all see bugs filed in trac. I expect all of us to pay attention to both those channels. I think we're all pretty approachable, and we try to be as findable as possible. We do not all read OLPCNews, nor do I expect OLPC's technical staff to cruise OLPCNews' forums in search of bug reports. I do not count proactively search for places people mention the word OLPC online as being findable. I answered a specific question about how the olpcnews.com/forum/ kind of people should report problems. It is in fact the same information mavrothal pointed out in the forum. Maybe that's not a good answer, but other than mavrothal and I, I haven't seen another answer to that question. As to your main topics, I would *love* it if we could all agree on a standard nomenclature for what we call deployments, because they're not all the same. OLPC has, I think, I pretty darn good feedback loop with the entities we consider deployments. But a lot of people use that term to mean a lot of different things - every time more than two XO laptops are in one place (or perhaps when there are two SoaS machines), it's a deployment to someone. There's nothing wrong with that, but when you then say there's a problem with getting input from deployments, it's hard to understand exactly what you mean. Particularly with volunteer-led or -driven deployments, it can be hard for anyone at OLPC to know what's going on. In your discussions with various teams, it would be great if you could emphasize the value of having a stable, findable, long-term technical contact that someone at OLPC knows about. That's a big help to us in any situation. More help is always welcome, although while you're doing all those things, please consider registering on trac and try filing one ticket. It's really not hard, and if the problem at hand is an apparent software/hardware bug, that's the best way to communicate it. - Ed P.S. I just saw Walter's reply, and things in Uruguay do indeed seem to work well. Those sorts of processes are what's needed in large deployments. On Aug 8, 2010, at 5:09 PM, Christoph Derndorfer wrote: On Sun, Aug 8, 2010 at 3:56 PM, Ed McNierney e...@laptop.org 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. 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
Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable (was: Re: OLPC 10.1.2 Release Candidate 1)
On Mon, Aug 9, 2010 at 9:36 AM, Walter Bender walter.ben...@gmail.com wrote: On Sun, Aug 8, 2010 at 5:09 PM, Christoph Derndorfer christoph.derndor...@gmail.com wrote: On Sun, Aug 8, 2010 at 3:56 PM, Ed McNierney e...@laptop.org wrote: 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. snip 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. It will need re-wording if this it something seen by the volunteers who test sugar and activities in their own time each week - some of them are the our teachers or education ministry decision makers. Can the same be said without it sounding like do it our way or go away? -- Item 3 probably could be dropped completely. It's not welcoming, and makes the project seem unapproachable. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable (was: Re: OLPC 10.1.2 Release Candidate 1)
Brenda - I'm assuming your teachers and education ministry decision makers don't normally interact with OLPC by asking questions on OLPCNews forums, which was the context and the specific question I was answering. The topic of, what are all the ways all interested parties worldwide communicate with OLPC is obviously a far more complex one, and not one I was attempting to answer. But people interested in communicating with OLPC and/or Sugar Labs should be able to find either of us - we usually try to point newcomers to our wiki at http://wiki.laptop.org. It's not perfect, but it's a good way to find pointers. But it is absolutely true that anyone who is volunteering (or getting paid) to test OLPC software and hardware should know how to submit a trac ticket. That is the mechanism we use to track reported problems, so using trac should be an essential part of the training any volunteer tester should get. While everyone likes nicely-researched and well-written problem reports, that shouldn't be an obstacle. If there's information missing on a ticket, people working on it can ask for more. But if the ticket's not there at all, we won't know there's a problem to fix. - Ed On Aug 8, 2010, at 6:00 PM, Brenda Wallace wrote: On Mon, Aug 9, 2010 at 9:36 AM, Walter Bender walter.ben...@gmail.com wrote: On Sun, Aug 8, 2010 at 5:09 PM, Christoph Derndorfer christoph.derndor...@gmail.com wrote: On Sun, Aug 8, 2010 at 3:56 PM, Ed McNierney e...@laptop.org wrote: 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. snip 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. It will need re-wording if this it something seen by the volunteers who test sugar and activities in their own time each week - some of them are the our teachers or education ministry decision makers. Can the same be said without it sounding like do it our way or go away? -- Item 3 probably could be dropped completely. It's not welcoming, and makes the project seem unapproachable. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable (was: Re: OLPC 10.1.2 Release Candidate 1)
On Mon, Aug 9, 2010 at 10:07 AM, Ed McNierney e...@laptop.org wrote: But it is absolutely true that anyone who is volunteering (or getting paid) to test OLPC software and hardware should know how to submit a trac ticket. That is the mechanism we use to track reported problems, so using trac should be an essential part of the training any volunteer tester should get. While everyone likes nicely-researched and well-written problem reports, that shouldn't be an obstacle. If there's information missing on a ticket, people working on it can ask for more. But if the ticket's not there at all, we won't know there's a problem to fix. Nobody is disputing that bug reports should go in the one true place -- however we need to be welcoming to people when we tell them this. I'll admit i'm not a fan of olpcnews.com, but they are where new contributors end up early on in their contributing -- if only because they show up in many search results. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Making OLPC / Sugar Labs more approachable (was: Re: OLPC 10.1.2 Release Candidate 1)
Every member of the OLPC technical staff is on the de...@laptop.org mailing list, and we all see bugs filed in trac. Sorry - that's not correct. I forgot that Mitch Bradley unsubscribed from de...@laptop.org last December, as he found the noise level has gotten out of control. He does, however, see and respond to bugs filed in trac. - Ed___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
