> -----Original Message----- > From: Patricia Shanahan [mailto:p...@acm.org] > Sent: Monday, March 21, 2016 09:10 > To: dev@openoffice.apache.org > Subject: Re: Can we add the value "N/A" to the Target Milestone field > > On 3/21/2016 8:59 AM, Kay Schenk wrote: > > On Sun, Mar 20, 2016 at 3:46 PM, Dennis E. Hamilton > <dennis.hamil...@acm.org > >> wrote: > > > >> I want to clarify this. > >> > >> I think the problem might be that "Resolved - Fixed" is being used > >> incorrectly. As far as I know, there are many cases where this > resolution > >> is used where one of "Resolved - Not an Issue" (though not too > often), > >> "Resolved - Irreproducible", "Resolved - Won't Fix", or "Resolved - > >> Obsolete" should be used. > >> > >> Is that what you are seeing, Kay? > >> > > > > ​Well maybe so. In the past, I have used RESOLVED-FIXED to determine > > what's been committed to our source, thus leading to a Target Release. > > Yesterday, I started going through RESOLVED-FIXED items to be sure > some of > > these fixed issued did have a Target Release. Some of these RESOLVED- > FIXED > > issues seem to be either user support issues/questions that do not > entail > > source code corrections at all, or similar type situations. In one of > the > > cases I sited above, I think the issue originator marked it with > > RESOLVED-FIXED, and really i don't know if this was the right thing to > do > > or not. [orcmid]
My impression is that original reporters rarely do this and might not even have the necessary karma. As you can see in one of the two you linked to, I was the guilty culprit [;<). > > > > So, we can use the new NONE (thank you Marcus!) as the Target Release, > or > > do something else to ignore these types of issues for verification in > a > > build. > > The problem is stemming from the use of BZ as both a code centric > problem > > reporting mechanism and a user support tool. > > I don't think it should be marked RESOLVED-FIXED unless it was actually > fixed, and therefore has a release in which the fix first appears. To > me, RESOLVED-FIXED with a target release of NONE is self-contradictory. > > What is the objection to changing the resolution to reflect reality? > > For example, if it was a user support issue that does not entail a > source code correction, shouldn't it be marked RESOLVED - NOT_AN_ISSUE > rather than RESOLVED - FIXED with a target date of NONE? [orcmid] I agree that RESOLVED - FIXED might be inappropriate in many cases. However, RESOLVED - NOT AN ISSUE is often too heavy-handed. It can clearly be an issue to users, especially when it is an identifiable usability matter although not a code bug, but still there may be some clear product-behavior deficiency. And the issue may be recognized as such by the project, too. The problem is "Issue for Whom," when it is about a deficiency in the product but not a bug in the conventional sense. Since we our software is user-facing, it would be good to own that such issues are issues for us as providers of something valuable to users. BZ is our basic mechanism for existence and attention to such cases. I also recall seeing "NOT AN ISSUE" used when IRREPRODUCIBLE might be a better matter (i.e., when the reporter fails to provide needed details to know specifically what the matter is). Also, sometimes the "fix" is elsewhere (i.e., documentation, workarounds on a wiki, whatever). I suppose that means CONFIRMED but not acted on until cleared up somehow, or a WONT-FIX that indicates the workaround is all that is coming. I think it comes down to specific cases. The ability to have a RESOLVED-FIXED with a "None" release target is useful, and we now have it available. We just need to use it appropriately. It just means that the fix is other than in a code release. We also need to make clear what the general uses of these categories are. That may already exist somewhere but it perhaps need to be surfaced more and promoted on the QA and DEV lists. > > Patricia > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
