Hi,
Helge Delfs schrieb:
Hi André,
André Schnabel wrote:
Why need issues regarding automation no detailed description? To me
as a volunteer (who is still somehow interested in automation) it is
important to quickly find issues in Issue Tracker. Best mean for this
is the summary.
With [automation] tag quicker to be found in the future ;-)
nonsense: component qa, subcomponent testscripts would give the same.
you could indeed write any information in the subject, so that it is
"more easy" to find. I'd suggest
[qa][automation][all platforms][p3][confirmed] [developer on vacation]
maybe we can extend this, so that we have not much more than 2
characters for the real issue.
I think we don't need the log of the recent QA-Session as it is our
daily job to handle these problems and I know hat you're talking
about. If the description to reproduce an issue is not detailed enough
even a well experienced QA member has problems to reproduce this. But
we shouldn't mix the things:
No Helge - I do not mix things. What I like to say is, that it is very
hard for people who do not work day-by-day with such problems to read
and understand issues if the description is to short or imprecise.
While the description is still ok for you - it is hard to step in for
people who like to help. I hope, you like toher people to help with your
work.
While working within the community you should always work on two things:
1st make your job (that's obvious)
2nd help other people to help you (makes more work for you at first
hand, but will give a lot of helping hands).
At the moment I feel, automation team is going exactly the same route.
Recheck your feelings if you compare the 'quality' of issues to be
submitted if they have to be reproduced manualy or with an automated
script in hands.
e.g. - take this issue:
http://qa.openoffice.org/issues/show_bug.cgi?id=92593
I'd guess hardly anybody could verify if this has been implemented
correctly, without requesting more information. (Well - I have an idea,
what the issue is about, but I am not sure).
Just an example - and I'd guess, you (or someone who did request the
change) will verify and close the issue. But if the issue gets out of
your scope (for whateever reason - busy with other tasks, leaving the
project ..), hardly anybody else can close the issue.
To be clear about this: I don't think, this is a critical problem - but
surely something that could be improved.
André
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
