Hi Dave, There are two projects in process right now. 1. Looking through the GPA footage up on the google video site and see ifyou can create a couple of feel-good, cool, You Tube style videos from it.
2. A video showing off the book reading capabilities of Sugar. Thanks, Caroline On Mon, Aug 3, 2009 at 8:48 PM, Dave C <[email protected]> wrote: > ... 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 <[email protected]> > *To:* iaep <[email protected]>; Sugar-dev Devel < > [email protected]>; Sugar Labs Marketing < > [email protected]> > *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 [email protected]. 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<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 > [email protected] > http://lists.sugarlabs.org/listinfo/marketing > > > _______________________________________________ > Marketing mailing list > [email protected] > http://lists.sugarlabs.org/listinfo/marketing > > -- Caroline Meeks Solution Grove [email protected] 617-500-3488 - Office 505-213-3268 - Fax
_______________________________________________ Marketing mailing list [email protected] http://lists.sugarlabs.org/listinfo/marketing
