[Marketing] First step towards an efficient feedback process

[David Farning]

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