[IAEP] Is again Community Influence - Re: Lets Get Satisfaction (was: Community Influence)

[Caroline Meeks]

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?
*
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.
>
>         --Fred
>
>
>
> On Wed, Jul 29, 2009 at 10:41 AM, Sebastian Dziallas <sebastian at when.com>wrote:
>
>> 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?",...).
>>
>> --Sebastian
>>
>> > 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
>> http://lists.sugarlabs.org/listinfo/iaep
>>
>
>
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>



-- 
Caroline Meeks
Solution Grove
Caroline at SolutionGrove.com

617-500-3488 - Office
505-213-3268 - Fax
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/iaep/attachments/20090730/98d49e79/attachment-0001.htm