Ultimately, this problem falls on other people's shoulders, not mine, so I only offer this as hopefully helpful advice.
What you are saying here is technically and procedurally correct. But I've been doing this (software development) for well over 2 decades and my experience tells me that there is a critical mass beyond which this is simply not practical. To Adam's point below: the 'age' should not be based on the date of the initial report, but rather the last activity (comment, update, whatever). Whether there is sufficient information to reproduce is sort of irrelevant. As a practical manner, you want to manage the work that you organizationally can and will do. Not the work that you would do if time & resources were infinite. If there has been no activity on an issue for a long time, there becomes a very high probability, no matter WHAT level of information is captured in the report, that it will simply not ever be acted upon. No matter what the level of detail of the information, after a long time, the _relevancy_ of that information also becomes suspect. Unless the information can be verified as applicable to current revisions - which requires manually confirm that it does, then it may not be useful information at all. So, to Jukka's a - b- c checks below, the problem is, if you have a zillion old, inactive issues, many stemming from versions prior to major revisions, then who is going to go back and apply those checks to each issue? PDFBox has 408 'open' issues. Only 165 of them have been updated in the last year. That's 243 old issues, that no one has touched in a full year, that each would need someone to look at and make the a - b - c assessment on. My contention is that that is not necessary. Old, inactive issues are not truly 'open' in the practical sense because the community has not mentally kept them open - only the issue tracker has. IF an old issue resurfaces as something that needs to be addressed, then either a new issue can be created or the old one can be re-opened. Closing an issue as 'stale' does not mean the information is lost. It simply removes it as part of the noise when you are looking at open issues and trying to prioritize. It is still searchable in Jira and retrievable and if necessary can be re-opened. As I said, it is not really my personal burden that I am trying to make lighter here with this advice. I am just trying to help here. Ultimately, you committers know how much time & effort you can afford to put towards issue management so it is your call. I will go along with and support whatever you guys decide. Cheers, -Mel -----Original Message----- From: Jukka Zitting [mailto:jzitt...@adobe.com] Sent: Thursday, December 02, 2010 4:35 AM To: dev@pdfbox.apache.org Subject: Re: JIRA bug cleanup? Hi, On 02/12/10 00:20, a...@swmc.com wrote: > If there's enough information to confirm the problem, then it should stay > open no matter what the age of the report. If there's not enough info > then we post a comment to try to get more info; if we can't get enough > information then close it as "unable to reproduce". Just my two cents... +1 I wouldn't mass-resolve old issues as there's still value in there. If people are checking whether you still can reproduce an old problem, it would be good to also add a note in the issue that you've done so. Basically: a) can reproduce -> note which version you tried b) can not reproduce -> resolve as unable to reproduce c) not enough information -> resolve as incomplete The difference between b and c is whether the issue contains enough information to even try reproducing the problem. For example we have many issues with no test documents or other test cases (manual or in code), which should probably be resolved as incomplete unless it's obvious what the problem is (like if there's an NPE stack trace with line numbers, etc.). BR, Jukka Zitting
smime.p7s
Description: S/MIME cryptographic signature
