Loading...
 

Batch actions on the bug tracker

Proposal to be applied to the bug tracker in dev.t.o (http://dev.tiki.org/tracker5)


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#Trackers

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




Opinions?

Copy of the former discussion about this topic in the tikiwiki-devel list

http://old.nabble.com/dev.t.o-tracker5-organization%3A-period-before-automatic-change-of-status--to30108221.html#a30127352

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.

Keywords

The following is a list of keywords that should serve as hubs for navigation within the Tiki development and should correspond to documentation keywords.

Each feature in Tiki has a wiki page which regroups all the bugs, requests for enhancements, etc. It is somewhat a form of wiki-based project management. You can also express your interest in a feature by adding it to your profile. You can also try out the Dynamic filter.

Accessibility (WAI & 508)
Accounting 7.x
Administration
Ajax 2.x
Articles & Submissions
Backlinks
Banner
Batch 6.x
BigBlueButton audio/video/chat/screensharing (5.x)
Blog
Bookmark
Browser Compatibility
Calendar
Category
Chat
Comment
Communication Center
Consistency
Contacts Address book
Contact us
Content template
Contribution 2.x
Cookie
Copyright
Credits 6.x
Custom Home (and Group Home Page)
Database MySQL - MyISAM
Database MySQL - InnoDB
Date and Time
Debugger Console
Directory (of hyperlinks)
Documentation link from Tiki to doc.tiki.org (Help System)
Docs 8.x
DogFood
Draw 7.x
Dynamic Content
Preferences
Dynamic Variable
External Authentication
FAQ
Featured links
Feeds (RSS)
File Gallery
Forum
Friendship Network (Community)
Group
Help
History
Hotword
HTML Page
i18n (Multilingual, l10n, Babelfish)
Image Gallery
Import-Export
Install
Integrator
Interoperability
Inter-User Messages
InterTiki
jQuery
Kaltura video management
Karma
Live Support
Logs (system & action)
Lost edit protection
Mail-in
Map
Menu
Meta Tag
Missing features
Visual Mapping 3.x
Mobile Tiki and Voice Tiki
Mods
Modules
MultiTiki
MyTiki
Newsletter
Notepad
OS independence (Non-Linux, Windows/IIS, Mac, BSD)
Organic Groups (Self-managed Teams)
Payment 5.x
Performance Speed / Load / Compression / Cache
Permission
Poll
Profiles
Quiz
Rating
Realname
Report
Revision Approval
Score
Search engine optimization (SEO)
Search
Security
Semantic links 3.x
Share
Shopping Cart 5.x
Shoutbox
Site Identity
Slideshow
Smarty Template
Social Networking
Spam protection (Anti-bot CATPCHA)
Spellcheck
Spreadsheet
Staging and Approval
Stats
Survey
Syntax Highlighter (Codemirror)
Tablesorter
Tags 2.x
Task
Tell a Friend, alert + Social Bookmarking
Terms and Conditions
Theme
TikiTests 2.x
Timesheet
Token Access
Toolbar (Quicktags)
Tours
Trackers
TRIM
User Administration
User Files
User Menu
Watch
WebHelp
Webmail and Groupmail
WebServices 3.x
Wiki 3D
Wiki History, page rename, etc
Wiki plugins extends basic syntax
Wiki syntax text area, parser, etc
Wiki structure (book and table of content)
Workspace and perspectives 4.x
WYSIWTSN 4.x
WYSIWYCA
WYSIWYG 2.x
XMLRPC




Useful Tools