Joost Andrae schrieb: > Hi Mechtilde, > >> >> I think a good first step will be to do the communication between the >> I-Teams and the corresponding QA-Teams. > > A QA representative is always part of the iTeam. An iTeam should consist > at least of representatives of QA, documentation, development and user > experience. An iTeam is often used when features are planned and developed. > > >> >> Christian (cloph) wrote some good points in his mail. I will citate. >> >> Developers should not be bothered with QA. >> The developers should .. be interested in QA. >> It should be clear what QA-members can ... do to verify the >> changes. In the cws and in future to prevent regressions. >> >> </citate> > > +1 > >> >> One goal should be to do these things also in the other teams. this will >> be a great step for the collaboration. > > To work together with the application related QA teams is a first step > to be involved into working on child workspaces. On the other hand > people who contribute by confirming unconfirmed issues is another > important thing because this disburdens developers to spend more time on > reproducing such issues. I believe you already helped the DBA project in > such a way :)
Confirming issues is a part of the work of the QA-Team members or the coordination of this. But one premise therefore is a good motivation through a good communication to the Sun-Developers and Sun-QA. So the quality of the Community-QA depends on this Regards Mechtilde -- Dipl. Ing. Mechtilde Stehmann ## http://de.openoffice.org ## Ansprechpartnerin für die deutschsprachige QA ## Freie Office-Suite für Linux, Mac, Windows, Solaris ## Meine Seite http://www.mechtilde.de ## PGP encryption welcome! Key-ID: 0x53B3892B --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
