[Sugar-devel] First step towards an efficient feedback process

[Christoph Derndorfer]

Quite frankly speaking I don't understand why the deployment related
conversations and feedback should be kept on IAEP when most of it
(especially at early stages of deployments and school projects, which is
were most small and large efforts are at the moment) will be of a relatively
technical
nature. As an example let me mention the Austrian pilot where during
my visits I'm normally
dealing with issues such as laptops not shutting down, activities being
deleted and collaboration not working as expected. The teachers there have a
fairly good idea of what they would want to use the laptops for if they or
the children didn't hit technical roadblocks that slow the classroom usage
down ever so often. It's only once we moved a bit behind those early
technical hickups that the discussions about the "good stuff" (education and
whatnot) will start to take place.
Having said that I personally believe that the core consideration in such a
feedback process should be to have someone dedicate him- or herself to it.
As Greg Smith showed so well at OLPC a single person at an organization can
make all the difference when it comes to communication between deployment
and developer communities.

At the same time deployments, regardless how large or small, should be
encouraged to offer at least a single (and reliable!) point of contact for
feedback collection. I really liked the list at
http://wiki.sugarlabs.org/go/Deployment_Team/Places that Tomeu started back
in February, however I just realized that (unless I missed something) the
people listed on that page have never been contacted in a structured manner
to give feedback.

So, to end this with an actionable item I would suggest that we start
flashing out a process and preferably an actual questionnaire of some kind
to be sent to people in deployments listed on the page mentioned above or
who we know personally (and subsequently encourage to sign up to the page
above;-) by the time brainstorming for 0.88 starts. With the 6-month release
cycle we have the opportunity to organize structured and timely feedback
flows twice a year.

At the same time we should make it as easy as possible for people to leave
their feedback, and when I say "as easy as possible" I'm not thinking of a
mailing-list, Trac or some wiki-template. Instead of scaring people away
with lots of tech-talk (like we do on
http://wiki.sugarlabs.org/go/Submit_Bugs/Problems at the moment) simply put
feedback at sugarlabs.org in <h1> on key locations of the wiki and Web site.

Anyway, it's getting late, time to grab some sleep...

Christoph

On Mon, Aug 3, 2009 at 11:55 PM, David Farning <dfarning at sugarlabs.org>wrote:

> One of the challenges over the next couple of months will be figuring
> out how to turn 'feedback' from deployments into useful 'information'
> which the bug squad and deployment team can use.
>
> As a first step, I would like to suggest that we keep deployment
> related threads on iaep at sl.o.  After all, deployments are the
> education part of the it's an education project.  There will be a
> number of benefits to this:
>
> 1.  Developers 'like' to work from bug trackers.  Our bug tracker is
> at dev.sugarlabs.org .  An example of a good bug report is at
> http://dev.sugarlabs.org/ticket/1100 .  In this report Gary does a
> good job of clearly describing the problem.  It is very common for bug
> reports to turn into conversation very similar to mailing list
> conversations as the bug reporter and bug fixer narrow in on the exact
> cause of the bug.  There is some very useful metadata at the top
> report describing exactly which version and component you can find the
> bug.  Finally, there is a the Ownedby field.  If a bug is identified
> on a mailing list it is likely to be forgotten within minutes.  Once a
> bug is entered into the tracker, someone owns the bug until they
> assign it to someone else.
>
> 2.  Developers like to work from feature requests.  Sugar stores
> feature requests on the wiki at
> http://wiki.sugarlabs.org/go/Features/Back_Up_and_Restore . A good
> example of a feature request is
> athttp://wiki.sugarlabs.org/go/Features/Back_Up_and_Restore . The
> format of the feature request make it easy for developer to figure out
> how a new feature fits into the exist code base and how to prioritize
> the feature.
>
> These two process are not just 'make work.'  Most non-teachers, have
> very little grasp of the processes teacher use to keep a class room of
> squirmy kids focused on a learning objective.  It is just going to
> take awhile until we learn to understand deployers need and
> specialized vocabulary.
>
> 3.  By keeping the deployment discussion on iaep, we can work together
> to figure out how turn feedback into usable information for developers
> before turning it into bug reports or feature requests.
>
> 4.  We can create a culture in which deployers and developers equally
> respected members of the sugar community.
>
> 5.  By clearly splitting up the roles and responsibilities between
> developer and deployers we start to lay the foundation for reviving
> the deployment team.
>
> david
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
Christoph Derndorfer
co-editor, olpcnews
url: www.olpcnews.com
e-mail: christoph at olpcnews.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090804/4dd69244/attachment.htm