Hi Herbert, > Having a status of ACCEPTED would match to a workflow where ...
Yes, I am fully aware of that. I am just a bit reluctant to introduce such a change "by passing". 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.) So, I am completely open to having both ACCEPTED and STARTED, but I think it needs broader discussion. And, at the same time, it can easily be introduced any time later (after the migration). >>> 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. > 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. Then, however, this is a work flow problem, which can be solved without splitting DUPLICATE into two statuses. 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. So the issue would move from RESOLVED/DUPLICATE to VERIFIED/DUPLICATE to CLOSED, instead of today's RESOLVED/DUPLICATE->CLOSED. > 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". >> 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" ... Ciao Frank -- - Frank Schönheit, Software Engineer [email protected] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
