Re: [Sugar-devel] [SoaS] Where should we put our mixture of bugs, feature requests and misunderstandings as we develop curriculum
Also, as a developer I would need to see a list of the features and bugs most requested by deployments, and which deployments need them. It will be also useful when asking for help and recruiting more volunteers. Yes, exactly. We need a way for individuals to contribute individually to this. We need a system that is tolerant of bad reports, supports peer-to-peer problem solving, and creates a pattern of data and feedback that can be fed back upstream. I'm just not sure how to create this yet, if you have ideas on implementation please let me know. I am leaning towards Launchpad and I also will talk to Adam Holt about his experiences and how we can work with the support gang. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Where should we put our mixture of bugs, feature requests and misunderstandings as we develop curriculum
On Wed, Sep 30, 2009 at 08:27:46PM -0400, Caroline Meeks wrote: As I work with educators to create and write up curriculum we will discover problems. They will be a mixture of Sugar, Activities, SoaS and confusion. There are a bunch of ways we could deal with it. [...] 2. Everything is first posted to IAEP Please please don't do this - IAEP gets enough SoaS/distro noise as is. 3. Everyone tells me everything and I try to decide where to put it which has obvious problems This is it. If you imagine you're the deployment, you have to communicate upstream. I don't think, realistically, it's scalable for every deployment to do anything else. 4. Everything is put into Trac No, then trac (Sugar) becomes a dumping ground that includes a lot of downstream (SoaS, etc.) issues. Triage suggestions (but I'm not the expert): For example todays issues - Record is not recording audio - probably hardware SoaS issue. SoaS bug tracker. - Colors journal entries are not showing up as an image so I can't import it into another program like Cartoon Builder. Activity author / mailing list. - Cartoon builder is cool, I want to make my own characters but it seems really hard in Sugar to draw a bit, save, draw a bit more, save under a new name, how can I do that more easily. Activity author / mailing list. - I'd like to save a figure out of FlipSticks and put him into cartoon builder. Is there a way to save a flipstick image? Activity author / mailing list. Thanks, Caroline Martin pgpijE34Z0TFl.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Where should we put our mixture of bugs, feature requests and misunderstandings as we develop curriculum
Hi Caroline, Apologies for not introducing myself to the lists before my first post, but workflow of issues is something that sparked a neuron or two! 2009/10/1 Caroline Meeks carol...@solutiongrove.com As I work with educators to create and write up curriculum we will discover problems. They will be a mixture of Sugar, Activities, SoaS and confusion. There are a bunch of ways we could deal with it. 1. Everything goes into Launchpad soas answers and we sort it out from there. 2. Everything is first posted to IAEP, discussed and sorted out and then put into Dev, Launchpad soas or into a wiki page somewhere or just lost in the mailing list archives 3. Everyone tells me everything and I try to decide where to put it which has obvious problems 4. Everything is put into Trac Here's a suggested workflow: Issue identified with SoaS Add Q https://answers.launchpad.net/soas/ Immediate Q answered Decisions to make Answerer(s) - If substantive, invite query to be discussed on list - If Sugar bug, then port to http://dev.sugarlabs.org/ - If repeated/general Q, then click Add to FAQ Rationale: Launchpad Answers is friendlier to newbies than Trac. Answers allows the user to own the question = they get to decide if their Q was answered sufficently to close the ticket. It's very easy to create a FAQ in Launchpad Answers. Trac is powerful for software development, but is only adequate for user support. Some things (like curriculum changes or substantive issues) deserve to be forwarded to mailing list. Cheers all, Tim http://timmcnamara.co.nz http://twitter.com/timClicks ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
