[Marketing] sorry...

[Dave C]

.... that I haven't responded until now. I have been taking a multiple-week  video editing class. I would definitely like to edit more videos for you all. Sorry again about the delay, but there is actually no internet access at the campus.  Let me know what you want done and I can begin work asap.

Please forward this message to list serve as I can't send to it for some reason



Dave C. 

 



________________________________
From: David Farning <dfarning at sugarlabs.org>
To: iaep <iaep at lists.sugarlabs.org>; Sugar-dev Devel <sugar-devel at lists.sugarlabs.org>; Sugar Labs Marketing <Marketing at lists.sugarlabs.org>
Sent: Monday, August 3, 2009 11:10:15 AM
Subject: [Marketing] First step towards an efficient feedback process

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
_______________________________________________
Marketing mailing list
Marketing at lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/marketing



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/marketing/attachments/20090803/9a156976/attachment.htm