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

[David Farning]

On Mon, Aug 3, 2009 at 2:01 PM, Christoph
Derndorfer<christoph.derndorfer at gmail.com> wrote:
> 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.

For the same reasons that splitting roles and responsibilities between
Sugar Labs, Fedora, and OLPC has created some effective abstraction
barriers.  These barriers have cleaned up Sugar deployments quite a
bit.

In order to 'scale' up support we need a set of process and
conventions for communicating between deployments and develops.

> 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.

All true.  Taking this argument a step further in context of Sugar
Labs;  The underling challenge is not that deployments have technical
problems, the challenge is creating methods for communicating these
problems as usable information to develops.

> 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.

Again true.  Have you seen the draft project roadmap I sent to iaep I
sent a few weeks ago?

> 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.

Again true: Taking this argument a step further in context of Sugar
Labs;   First, how to we attract and engage a person with Greg's
skills and knowledge?  Second, how do we scale that person?

Open source development _depends_ on people scratching their own
itches.  If a deployment wants a new feature or bug fixed it is in
their best interest to help make that happen.  Thus deployments _must_
become participants in Sugar Labs rather than consumers if they want
their itches scratched.

> 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 would turn this on it's head and say, "For deployment support to
scale, at least one member of a deployment should become an activate
participant in Sugar Labs."

> 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.

Again, this depends on 'having a we' without consideration for who
that 'we' is that is expected to do the work.  If a deployment want
support of new feature they must become part of that 'we.'

> 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.

You have taken your argument all the way around and reached the same
conclusion as I did:)  Developer use tech-talk. Deployers (for the
most part) don't.  The challenge is creating processes (bridges) which
meet the needs of two important constituencies,  deployers and
developers.

david

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