Since we are using Tiki6 in dev.tiki.org, we could start thinking in using the feature to automatically change status of tracker items from open to pending after a certain period of time of no activity (6 months?), and warn users with an email two weeks before this is going to happen, so that they can go and update their bug report, and close it if appropriate, etc.
See the documentation of the feature with the example of tracker items:
This way, we might have a higher rate of accurate tracker items in the bug tracker.
After X1 months a new branch is expected to have been released, and that user might check, at least, if that bug is still active in the new branch, etc.
And after X2 months of no activity, change the bug to closed?
Potential values for X1 and X2:
- X1: 6 months
- X2: 18 months
On 2010-11-03 07:04, Xavier de Pedro wrote: > > Ok, chealer, I understand what you mean. > > > > Therefore, are you proposing that we don't use automatic changing of ANY > > status? More or less. I'm saying 2 things: A) Our BTS is currently not good to do this. B) Even with a perfect BTS, 6 months of no activity is short. It may be even normal that a bug has no activity. If the report is perfect from the start, there is often little activity besides votes (which our BTS doesn't have), other bugs being marked as duplicates (which our BTS doesn't really have), people subscribing to the report and sometimes comments. So I'm very concerned about automated changes, particularly in the current situation, but not completely opposed. > > Or from open to pending yes, but not automatically from pending to closed? > > > > And with no period at all (NEVER do that)? Or with higher time frames > > for changes from open to pending, and from pending to closed? > > If so, which time frames would be adequate for your point of view in the > > Tiki bug tracker? > > Years? How many? > > Only to version which are no longer supported? It all depends on how carefully the automatic closure is. If we only change unconfirmed *bugs* (not feature requests) which had no recent activity (including comments) to pending after each "LTS" release and after asking the submitter to try reproducing, I think it's reasonable. It also depends on who can reopen the report. Typically, we ask the reporter to try reproducing, but if he's dead, he won't reply and other people affected subscribed to the report will want to reopen. It's frustrating if they can't and have to open a new report. In some BTS-s even the reporter can't reopen. But if we're just looking at the last modification time, I think it's not even worth it, whatever the time frames. I would like to see automated closing of pending items, but this is delicate too. > > Xavi > > > > > > Al 02/11/10 18:43, En/na Filipus Klutiero ha escrit: >> >> On 2010-11-01 16:17, Xavier de Pedro wrote: >> >> >>> >>> Hi all: >>> >>> >>> >>> Since we are using Tiki6 in dev.tiki.org, we could start thinking in >>> >>> using the feature to automatically change status of tracker items from >>> >>> open to pending after a certain period of time of no activity (6 >>> >>> months?), and warn users with an email two weeks before this is going to >>> >>> happen, so that they can go and update their bug report, and close it if >>> >>> appropriate, etc. >>> >>> >>> >>> See the documentation of the feature with the example of tracker items: >>> >>> http://doc.tiki.org/Batch >>> >>> >>> >>> This way, we might have a higher rate of accurate tracker items in the >>> >>> bug tracker. After 6 months a new branch is expected to have been >>> >>> released, and that user might check, at least, if that bug is still >>> >>> active in the new branch, etc. >>> >>> >>> >>> And after 18 months of no activity, change the bug to closed? >>> >>> >>> >>> Opinions? >>> >>> >> >> Yes :-) I was pissed off by automated bug closing no later than today, >> >> and it wasn't the first time. Today was from Mozilla, which uses >> >> Bugzilla. The message said the bug had had no activity in 500 days. I >> >> had actually voted for that bug just a few months ago. Does it show I >> >> was angry? https://bugzilla.mozilla.org/show_bug.cgi?id=481834 >> >> >> >> I have no doubt things would be much worst for Tiki, which doesn't use a >> >> system designed specifically to be a BTS. At this time, the best we >> >> could do is to use "After last modification", but I'm guessing this is >> >> really looking at the item's last modification property, which doesn't >> >> take comments into account. The Mozilla triager at least only acted on >> >> unconfirmed bug reports. >> >> >> >> I looked at the oldest outstanding unconfirmed bug report I filed >> >> against Debian and found >> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=285270 which was filed >> >> in December 2004. Even though I've been very negligent in updating my >> >> Debian reports in the last years, this bug is unfixed. Debian does >> >> almost no automated bug closure. I'm very happy I wasn't asked 10 times >> >> to confirm the bug still existed. And I'm sure this is no exception. In >> >> my experience, the fraction of reports which are resolved in 6 months is >> >> pretty low. >> >> >> >> If we have time to work on the BTS, I wish we start with other things, >> >> like automating subscription to reports for submitters. This could allow >> >> us one day to implement automated closing of reports reasonably.