Changes

* Who tests activities?

** I was almost convinced that it is a downstream task but... OLPC does not support activities (it's an odd case, I know of no downstream project in the same situation). I've seen [[User:Mchua|Mchua's]] post about moving it to Sugar Labs, let's make a good plan on it Wed. [[User:Marcopg]]

 

** I think that Activities should be tested by individual Activity project groups, since Activities are independent subprojects. I don't think that the core Sugar Labs bugsquad should be testing Activities. I also don't think that internal OLPC QA should be testing Activities, other than making sure the ones we ship are ship-quality on XOs (by coordinating with the individual Activity projects, ideally).

* Making Activities platform-independent

 

** The question of "who tests Activities?" is somewhat related to the issue of making activities platform independent, similarly to firefox plugins (I will elaborate on it in the meeting). [[User:Marcopg]]

** Who tests activities?

* If we move activities testing upstream, how do we move tickets? If we don't move them, where should user oriented information be hosted?

*** I was almost convinced that it is a downstream task but... OLPC does not support activities (it's an odd case, I know of no downstream project in the same situation). I've seen [[User:Mchua|Mchua's]] post about moving it to Sugar Labs, let's make a good plan on it Wed. [[User:Marcopg]]

** (not very clear on this, and it's not strictly a testing issue but it certainly intersects with it). [[User:Marcopg]]

*** I think that Activities should be tested by individual Activity project groups, since Activities are independent subprojects. I don't think that the core Sugar Labs bugsquad should be testing Activities. I also don't think that internal OLPC QA should be testing Activities, other than making sure the ones we ship are ship-quality on XOs (by coordinating with the individual Activity projects, ideally).

* We should report tickets upstream as much as possible, but how do we ensure downstream is able to track those which are interesting to them?

 

** If OLPC misses a fix because it cares about because it's tracked only upstream we are going to be in troubles  :)  For the record: Greg suggestion: don't try too hard to solve the issue because it's largely an unsolved one in foss. [[User:Marcopg]]

** Making Activities platform-independent

** The responsibility burden for this falls on downstream, in my opinion. [[User:Mchua|Mchua]] 07:28, 6 December 2008 (UTC)

*** The question of "who tests Activities?" is somewhat related to the issue of making activities platform independent, similarly to firefox plugins (I will elaborate on it in the meeting). [[User:Marcopg]]

* How does a tester know a problem is very likely downstream?

 

** garycmartin just reported an hardware related issue to dev.sl.o, that's something we can certainly avoid with simple guidelines. Action item -> write down such guidelines! [[User:Marcopg]]

** If we move activities testing upstream, how do we move tickets? If we don't move them, where should user oriented information be hosted?

** This is a big question for me, because I think the "how do we ensure downstream is able to track those which are interesting to them?" problem is something that's downstream's problem, and downstream is currently me. ;) [[User:Mchua|Mchua]] 07:28, 6 December 2008 (UTC)

*** (not very clear on this, and it's not strictly a testing issue but it certainly intersects with it). [[User:Marcopg]]

* How can we manage expectations?

 

** It's going to be hard at the beginning, both for developers and testers. We need to manage expectations so that we don't make people upset. Worth considering a mailing list post explaining what is going on, what we are planning to do about it, and to please be patient while things settle down. Show the positive side of it! [[User:Marcopg]]

** We should report tickets upstream as much as possible, but how do we ensure downstream is able to track those which are interesting to them?

* How do we ensure that OLPC is comfortable with what we are doing?

*** If OLPC misses a fix because it cares about because it's tracked only upstream we are going to be in troubles  :)  For the record: Greg suggestion: don't try too hard to solve the issue because it's largely an unsolved one in foss. [[User:Marcopg]]

** This matters because OLPC is currently Sugar's largest downstream user by far. I'll try to raise the topic at the internal OLPC QA meeting this coming Monday. [[User:Mchua|Mchua]]

*** The responsibility burden for this falls on downstream, in my opinion. [[User:Mchua|Mchua]] 07:28, 6 December 2008 (UTC)

 

** How does a tester know a problem is very likely downstream?

*** garycmartin just reported an hardware related issue to dev.sl.o, that's something we can certainly avoid with simple guidelines. Action item -> write down such guidelines! [[User:Marcopg]]

*** This is a big question for me, because I think the "how do we ensure downstream is able to track those which are interesting to them?" problem is something that's downstream's problem, and downstream is currently me. ;) [[User:Mchua|Mchua]] 07:28, 6 December 2008 (UTC)

 

** How can we manage expectations?

*** It's going to be hard at the beginning, both for developers and testers. We need to manage expectations so that we don't make people upset. Worth considering a mailing list post explaining what is going on, what we are planning to do about it, and to please be patient while things settle down. Show the positive side of it! [[User:Marcopg]]

 

** How do we ensure that OLPC is comfortable with what we are doing?

*** This matters because OLPC is currently Sugar's largest downstream user by far. I'll try to raise the topic at the internal OLPC QA meeting this coming Monday. [[User:Mchua|Mchua]]