[IAEP] Is again Community Influence - Re: Lets Get Satisfaction (was: Community Influence)
tomeu at sugarlabs.org
Sat Aug 1 10:45:22 EDT 2009
On Fri, Jul 31, 2009 at 02:20, Caroline Meeks<solutiongrove at 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 seem to be currently evaluating tools,
> does anyone else have a user story they would like to share on how they would like to see teacher feedback and communication with developers supported?
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?
> On Wed, Jul 29, 2009 at 11:51 AM, Frederick Grose <fgrose at gmail.com> wrote:
>> http://idea.laptop.org/drupal5/ideatorrent is a resource that
>> OLPC's Volunteer Infrastructure Group have experimented with.
>> A sugarlabs.org variant may be an easy step.
>> It has the idea, solution, voting features, and possibly could be
>> configured to segregate questions, problems, praise, etc.
>> On Wed, Jul 29, 2009 at 10:41 AM, Sebastian Dziallas <sebastian at when.com>
>>> Walter Bender wrote:
>>> > It isn't obvious at first glance why this particular site appeals to
>>> > you. Could you describe its features and the problems you think they
>>> > address?
>>> It is the one I came across and a quick research (not very deep,
>>> admittedly) didn't result in many comparable alternatives - that's also
>>> why I asked for alternatives in the end.
>>> What I believe is: *we need to make it easy to submit feedback*
>>> The feedback at sl.o address was a beginning, but I think we need to
>>> explore other possibilities, too. GetSatisfaction looks - to me - like a
>>> good way of offering our users an easy, well designed interface, where
>>> they can enter their requests & issues.
>>> I mentioned some of its features already below (like the various kinds
>>> of feedback, the possibility of making the current state on an issue
>>> easily clear enough,m...). However, I think if we promote such a
>>> solution well enough, it might help us to get feedback even from those
>>> people, who're probably not that experienced with open source projects
>>> or even feared of entering a ticket in trac ("what the heck is a bug?",
>>> "why do I need an account here?" "what's this all about?",...).
>>> > thanks.
>>> > -walter
>>> > On Wed, Jul 29, 2009 at 9:35 AM, Sebastian Dziallas<sebastian at when.com>
>>> > wrote:
>>> >> Hi everybody,
>>> >> it's really good to see this discussion getting off the ground. While
>>> >> being at LinuxTag, we discussed with some folks how to improve the way
>>> >> of getting feedback from our users, without putting too much barriers
>>> >> in
>>> >> their way.
>>> >> So while looking around and at various issue tracking systems, I
>>> >> discovered GetSatisfaction. I had seen that before already, but wasn't
>>> >> sure of its current state. There you go: http://getsatisfaction.com/
>>> >> GetSatisfaction is also used by other open source projects like
>>> >> Songbird
>>> >> (which might also be a good place to an idea how such an instance
>>> >> looks
>>> >> like): http://getsatisfaction.com/songbird
>>> >> So as you can see, users gain various possibilities of interacting
>>> >> with
>>> >> the developers here. They can ask questions, report issues and so on.
>>> >> Others go ahead and comment and vote an entry up and down so that
>>> >> developers can see what's more and what's less important. Finally, a
>>> >> developer can also put a "we're working on it" or "we're aware of this
>>> >> problem" flag on an entry, to make the current state more obvious.
>>> >> In my opinion, this might be a good way of inviting more people to
>>> >> give
>>> >> us feedback (I'm not suggesting to abandon trac, I guess we should use
>>> >> that to track issues ourselves, too). For example, if we created such
>>> >> an
>>> >> instance and mentioned it in the next press release, I'm pretty sure
>>> >> it
>>> >> could work out well.
>>> >> Well, GetSatisfaction is a company. So they have various plans (also a
>>> >> free one, which looks like it would probably already be enough), while
>>> >> I
>>> >> guess we could also contact them directly.
>>> >> So. What do you think? Is this worth trying out? Any alternatives?
>>> >> I've already a personal account with them, but how do we proceed?
>>> >> Cheers,
>>> >> --Sebastian
>>> >> _______________________________________________
>>> >> IAEP -- It's An Education Project (not a laptop project!)
>>> >> IAEP at lists.sugarlabs.org
>>> >> http://lists.sugarlabs.org/listinfo/iaep
>>> IAEP -- It's An Education Project (not a laptop project!)
>>> IAEP at lists.sugarlabs.org
>> IAEP -- It's An Education Project (not a laptop project!)
>> IAEP at lists.sugarlabs.org
> Caroline Meeks
> Solution Grove
> Caroline at SolutionGrove.com
> 617-500-3488 - Office
> 505-213-3268 - Fax
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP at lists.sugarlabs.org
More information about the IAEP