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
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: [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
