Having a status of ACCEPTED would match to a workflow where ...
[...]
Just renaming STARTED to ACCEPTED is different, since STARTED was
effectively used as ACCEPTED most of the time. (or it was not used
at all.)
This was probably caused by the obvious usability bug in issuezilla
that selecting "ACCEPT" changed the status to "STARTED"!
While we are at the topic of issue status I would also suggest to
replace WORKSFORME with NOT_REPRODUCIBLE.
This might be discuss-worthy. Why do you think it would be better?
Because a lot of issues have a status WORKSFORME for most users.
Reproducing an issue is then hard work: it may require checking on
different platforms, testing in various locales, setting up a debug
environment, isolating the problem down to be reproducible reliably,
installing additional components, etc.
A status name NOT_REPRODUCIBLE means that none of the testers can
reproduce a problem. A status name WORKSFORME would suggest that the
issue can be marked as resolved if any tester does not experience the
problem directly. We should not encourage that kind of (sloppy)
testing by allowing a WORKSFORME status.
Hmm. If QA cannot reproduce the problem, then it is legitimate to
close
the issue as WORKSFORME. Of course, "cannot reproduce" should imply
that
reasonable efforts were done attempting to reproduce it. I don't think
that by simply renaming the status (and it isn't more than a renaming,
the meanings stays exactly the same) we can ensure that. People who
did
sloppy testing before, will do sloppy testing afterwards, too.
Renaming to NOT_REPRODUCIBLE doesn't help with sloppy testing but it
does not encourage it in the same way as WORKSFORME does. As an
analogy: Writing "Danger: Rat Poison!" discourages consumption better
than labeling something as "Delicious Candy"...
I see a lot of issues with the status DUPLICATE closed without any
thought or testing put into this. This would be fine if an issue is
reported multiple times. But there are also issues that deserve
additional testing because they are so very different on the surface.
The second kind of issues often have a common root cause.
Effectively, what you say is that a DUPLICATE issue is not
tested/verified, again, and while this is fine for a certain class of
DUPLICATEs (those which are *obviously* duplicate, i.e. describe the
same end user experience), there's another class of DUPLICATEs where
this is *not* fine: Those which describe completely different end user
experiences, but have the very same root cause.
Yes, that is my point: Different workflows -> different names
Then, however, this is a work flow problem, which can be solved
without
splitting DUPLICATE into two statuses.
So you are suggesting: Different workflows -> same name
To come back to the analogy mentioned above: A process that names
everything the same probably has a much higher fatality rate than a
process that labels and treats rat poison and candy as very different
things.
We just need to require that
issues from the second class must not be closed without verification.
That is, if you have an issue A which describes a bug X, and an
issue B
which describes Y (X and Y being completely different, from an end
user's point of view), and resolve A as duplicate of B, then just
give A
to QA, too.
It would be a very unwise use of resources if each and every issue
with DUPLICATE_ROOTCAUSE status had to go through the few core-QA
testers. Having third-party testers rechecking these issues with
builds containing the fix is a process with much better scalability.
They have the expertise to reproduce their problem whereas I don't
have the time to reproduce and check of each and every scenario myself
and then to guide and handhold the dedicated testing efforts.
Another aspect that is important to me is one of respect: When issue
reporters carefully research their issues and check for duplicates
before submitting their problems then having an issue resolved as
simple DUPLICATE is disrespectful of their contribution. And with
DUPLICATE issues regularly being closed automatically their valuable
insights and testing abilities get dismissed.
Yes, but ... again, the "closed automatically" here points to the
underlying problem in the workflow. Let's just fix this work flow, by
distinguishing between "resolve as duplicate", "verify as duplicate",
and "close".
A status name that distinguishes between these two workflows would
benefit everyone. And the issue of respect for the efforts of the
reporter should not be underestimated either.
I'm still in favor of removing PATCH, but I think there might be too
much resistance from the statistics-fans :-\
With an explicit patch flag which is orthogonal to the issue type
even
fans of statistics could be happy.
I'll try to raise that with the migration team, and the "statistics
stakeholders" ...
Thanks!
---
Herbert Duerr
du...@sun.com
Registered Office: Sun Microsystems GmbH
Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Commercial register of the Local Court of Munich: HRB 161028
Managing Directors: Thomas Schroeder, Wolfgang Engels
Chairman of the Supervisory Board: Martin Haering
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qa.openoffice.org
For additional commands, e-mail: dev-h...@qa.openoffice.org
