[Tracker-discuss] [issue16] Automatic issue expiration

Stephen Turnbull metatracker at psf.upfronthosting.co.za
Fri Apr 3 07:37:11 CEST 2009


Stephen Turnbull <stephen at xemacs.org> added the comment:

Skip Montanaro writes:
 > 
 > Skip Montanaro <skip at pobox.com> added the comment:
 > 
 > Brett> I still think that closing a pending issue after 14 days is a
 >     Brett> good idea.
 > 
 > Auto-close seems reasonable, but 14 days is too short, even if the submitter
 > can reopen by adding a new comment.  Consider the past week.  Lots of
 > experienced core developers were probably distracted from bug triage for at
 > least a week, what with tutorials, the conference and the sprints.  It will
 > take many of them a a few days just to get caught back up at work once they
 > return home, putting tickets they might have expressed interest perilously
 > close to being automatically closed.

Suggestion: I think a better way to handle this apparent problem would
be to document that "pending" should be used with care, only when the
requested information really is necessary to implement a resolution of
the issue.

Suggestion: I don't think an unassigned ticket should be classed as
"pending".  If the triager doesn't feel competent, and wants to act as
a "secretary" for the competent developer, they should assign to
themselves, then reassign to a competent developer when sufficient
information is available.  Ideally, no ticket should be closed without
a human being taking responsibility for it.

Thing is, what *pending* means is that a developer has *already*
"expressed interest", and found themselves *blocked* for lack of
information.  Why would a second developer be interested in that
ticket?  Sure, there will be one-of-a-kind reasons, but mostly I would
expect that during triage sweeps developers will ignore -- as best
they can, some things will just catch the eye, of course -- "pending"
tickets.  And they *should* ignore them, otherwise why have a
"pending" status?

 > What's the extra cost of bumping the auto-close interval to, say,
 > two months?

Having four times as many tickets that developers with little time to
spare have to skip over.  (Thus further decreasing the chance that
they'll look at any one of them.)

Also, although there may be some submitters like Tennessee who
actually do systematically respond to requests for information a month
later, I personally would do much better with a shorter deadline (for
me a 10-day deadline would be optimal).  And I would think the
majority of submitters aren't going to be doing anything "systematic",
they want a fix a.s.a.p., so they will respond as quickly as they can,
if only to say "er, how do I get the information you need?"

What's the benefit to keeping it open longer?  The only thing I can
see is that a second developer will look at it despite the "not enough
info" judgment of the first developer, and see something that the
first didn't.  How likely is that conjunction of events?  Isn't it
more likely that the second developer will go, "yup, a waste of my
time as expected: can't do anything without that information"?  And it
doesn't help the submitter, they've already been notified that
somebody responsible needs more information from them.  If they search
for "my bugs" it *should* show up (if not, I'd consider that a tracker
bug).

----------
nosy: +stephen

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue16>
_______________________________________________________


More information about the Tracker-discuss mailing list