Re: [IAEP] Is again Community Influence - Re: Lets Get Satisfaction (was: Community Influence)
On Fri, Jul 31, 2009 at 02:20, Caroline Meekssolutiongr...@gmail.com wrote: I've been working this week on stick failures and I've had a good conversation with Martin Dengler which I think is relevant to the problem we hope to solve with this new tool. My feedback from the field was vague, incomplete and built over a period of days. It was not structured QA, replicable bugs with logs attached. I also talked about features that are not in scope for the next few months (specifically creating a Stick solution that survives the washing machine). My hope is that every developer on this project goes to their local school or daycare and runs a Sugar Club and gets to experience trying to get good data on errors in a room with 10-20 kids where the kid who is experiencing a problem is really engaged and very upset that they can't do what they were trying to do, especially when all the other kids are! Actually mostly I hope you do this cause its actually a ton of fun. :) Things are working most of the time and kids love it. However, everyday I'm in class something weird happens with Sugar. At this point if I can get it to go away I don't report it. Its just too much time to fill out a trac ticket for unreplicable things that aren't fatal. I think we have a choice. We harrang and nag the people in the classroom to give us better info, thus chasing away most of them, or we encourage feedback and get a lot of bad data. I vote for creating a system that lets us aggregate the bad data enough to pull out the real issues. Following the agile traditional I write some stories. Today, for example, a stick didn't boot twice on one computer. It did boot on another. If I wanted to test that I need to boot another known good stick on that computer, and probably retry later with the problem stick, plus capture what points the boot stop and if its consistent. The problem is class ends at 12:30 and we have to be cross town at Dorchester at 1:00. And honestly I have more serious issues to work on right now. What I actually did was ignore it and move on. My hope is that with a nice AJAX UI I could very quickly make notes about this and in the process of typing see if someone else has already reported it. If I had a this system in place I would have noted what the error on the screen was (I could have taken a photo of the screen) and written: Stick failed to boot and the screen said dectecting USB blah blah stick booted on another computer. In my ideal world of this story there are many other people and they also write things like this. So lets say I' m the first. The next teachers goes to enter the same error. With the wonders of AJAX they see that for me the stick booted on another computer after this error. So they now go try it on another computer. Perhaps their immediate problem is solved. Over the next few weeks I keep an eye on that computer, does it happen again? Does it happen to that stick again? If it happens again does it work on a different USB port of the same computer, is the cord bad? What work arounds does the other teacher use? Does the other teacher see a repeat on the same machine...etc. so eventually, if its a real problem, over the course of weeks we get data. The data may not end up pointing to a bug that Sugar can fix, it might end up pointing to the need to write an FAQ. If you see this type of error try another USB port on the same computer. In this story we never need developer attention. Its a hardware issue. Its still a Sugar issue, its still a problem that we need to support Sugar users in solving. Indeed the people solving this problem are every bit as much members of the Sugar community as developers. Let me tell another story with a software bug: Activity X crashes when I have a bunch of people sharing it. - One report, not very actionable. Next person types in Activity X and sharing and sees the report above so adds theirs as a comment. Soon we have 25 reports each with different details. Some list the number of people sharing. Another whether it local or remote collaboration, another whether its wireless or not. With a bunch of reports we know that 1. Its important, lots of people want to share Activity X. 2. We probably see some patterns to the failure. 3. look through the 25 reports and find the tech savvy teacher who can collect logs. We can't do this if the 20 not so tech savvy teachers have any sort of emotional or logistical block to posting their incomplete bug reports. We also can't have developers having to categorize, close as duplicate 25 tickets! nor can we have developers feeling like each of these 25 people need an immediate personal response and thus they are overwhelmed. So thats the vision of where I want to go. Its going to take more then putting up a web page to get there. Little bit of Web 2.0 magic and lots of social engineering, probably gardners or the support gang helping quite a bit. As we
Re: [IAEP] Is again Community Influence - Re: Lets Get Satisfaction (was: Community Influence)
Oops, sent too soon. On Aug 1, 2009, at 10:16, Luke Faraone l...@faraone.cc wrote: On Aug 1, 2009, at 7:45, Tomeu Vizoso to...@sugarlabs.org wrote: I think OLPC also had this problem and decided to use rt for user support and trac for tracking development issues. May be worth asking Adam Holt about it? Tomeu, As someone who worked with the RT system, I can say that it works very well as a CRM for traditional organizations, but it suffers from it's clear separation between employees and users. The strongpoint of using a tool such as GetSatisfaction or UserVoice is that it scales well, by allowing people to ... Assist one another and provide a public archive of past problems and encounters. It lets anyone join in, and provides for a richer community experience. -- Luke Faraone ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Is again Community Influence - Re: Lets Get Satisfaction (was: Community Influence)
On Sat, Aug 1, 2009 at 19:19, Luke Faraonel...@faraone.cc wrote: Oops, sent too soon. On Aug 1, 2009, at 10:16, Luke Faraone l...@faraone.cc wrote: On Aug 1, 2009, at 7:45, Tomeu Vizoso to...@sugarlabs.org wrote: I think OLPC also had this problem and decided to use rt for user support and trac for tracking development issues. May be worth asking Adam Holt about it? Tomeu, As someone who worked with the RT system, I can say that it works very well as a CRM for traditional organizations, but it suffers from it's clear separation between employees and users. The strongpoint of using a tool such as GetSatisfaction or UserVoice is that it scales well, by allowing people to ... Assist one another and provide a public archive of past problems and encounters. It lets anyone join in, and provides for a richer community experience. That's a very good argument. Thanks, Tomeu -- Luke Faraone ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Is again Community Influence - Re: Lets Get Satisfaction (was: Community Influence)
On Friday 31 Jul 2009 5:50:48 am Caroline Meeks wrote: I think we have a choice. We harrang and nag the people in the classroom to give us better info, thus chasing away most of them, or we encourage feedback and get a lot of bad data. I just tried SoaS in a virtual machine and found some simple ways to get diagnostic info. If you get to the screen with SoaS 1 text: Pressing ESC reveals startup messages. The last one is important. If you can't get to the graphical screen. Restart and press TAB twice at the message (Automatic boot in 1 second). This will reveal the bootstrap command. Removing 'rhgb' (RedHat graphical boot?) using backspace and pressing ENTER will print diagnostic messages. Removing 'quiet' will print even detailed messages. Again, the last message will suffice. FYI .. Subbu ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] Is again Community Influence - Re: Lets Get Satisfaction (was: Community Influence)
I've been working this week on stick failures and I've had a good conversation with Martin Dengler which I think is relevant to the problem we hope to solve with this new tool. My feedback from the field was vague, incomplete and built over a period of days. It was not structured QA, replicable bugs with logs attached. I also talked about features that are not in scope for the next few months (specifically creating a Stick solution that survives the washing machine). My hope is that every developer on this project goes to their local school or daycare and runs a Sugar Club and gets to experience trying to get good data on errors in a room with 10-20 kids where the kid who is experiencing a problem is really engaged and very upset that they can't do what they were trying to do, especially when all the other kids are! Actually mostly I hope you do this cause its actually a ton of fun. :) Things are working most of the time and kids love it. However, everyday I'm in class something weird happens with Sugar. At this point if I can get it to go away I don't report it. Its just too much time to fill out a trac ticket for unreplicable things that aren't fatal. I think we have a choice. We harrang and nag the people in the classroom to give us better info, thus chasing away most of them, or we encourage feedback and get a lot of bad data. I vote for creating a system that lets us aggregate the bad data enough to pull out the real issues. Following the agile traditional I write some stories. Today, for example, a stick didn't boot twice on one computer. It did boot on another. If I wanted to test that I need to boot another known good stick on that computer, and probably retry later with the problem stick, plus capture what points the boot stop and if its consistent. The problem is class ends at 12:30 and we have to be cross town at Dorchester at 1:00. And honestly I have more serious issues to work on right now. What I actually did was ignore it and move on. My hope is that with a nice AJAX UI I could very quickly make notes about this and in the process of typing see if someone else has already reported it. If I had a this system in place I would have noted what the error on the screen was (I could have taken a photo of the screen) and written: Stick failed to boot and the screen said dectecting USB blah blah stick booted on another computer. In my ideal world of this story there are many other people and they also write things like this. So lets say I' m the first. The next teachers goes to enter the same error. With the wonders of AJAX they see that for me the stick booted on another computer after this error. So they now go try it on another computer. Perhaps their immediate problem is solved. Over the next few weeks I keep an eye on that computer, does it happen again? Does it happen to that stick again? If it happens again does it work on a different USB port of the same computer, is the cord bad? What work arounds does the other teacher use? Does the other teacher see a repeat on the same machine...etc. so eventually, if its a real problem, over the course of weeks we get data. The data may not end up pointing to a bug that Sugar can fix, it might end up pointing to the need to write an FAQ. If you see this type of error try another USB port on the same computer. * * *In this story we never need developer attention. Its a hardware issue. Its still a Sugar issue, its still a problem that we need to support Sugar users in solving. Indeed the people solving this problem are every bit as much members of the Sugar community as developers. * *Let me tell another story with a software bug:* * Activity X crashes when I have a bunch of people sharing it. - One report, not very actionable. * Next person types in Activity X and sharing and sees the report above so adds theirs as a comment. Soon we have 25 reports each with different details. Some list the number of people sharing. Another whether it local or remote collaboration, another whether its wireless or not. With a bunch of reports we know that 1. Its important, lots of people want to share Activity X. 2. We probably see some patterns to the failure. 3. look through the 25 reports and find the tech savvy teacher who can collect logs. We can't do this if the 20 not so tech savvy teachers have any sort of emotional or logistical block to posting their incomplete bug reports. We also can't have developers having to categorize, close as duplicate 25 tickets! nor can we have developers feeling like each of these 25 people need an immediate personal response and thus they are overwhelmed. *So thats the vision of where I want to go. Its going to take more then putting up a web page to get there. Little bit of Web 2.0 magic and lots of social engineering, probably gardners or the support gang helping quite a bit.* *As we seem to be currently evaluating tools, does anyone else have a user story they would like to share on how they
