> Thing is, what *pending* means is that a developer has *already*
> "expressed interest", and found themselves *blocked* for lack of
> information.

You completely misunderstand. It means something entirely different.

It means that whoever looked at the issue thinks it should be closed,
but on the off-chance that somebody might object, sets it to pending
only. No developer is interested anymore - it's about to be closed.

Regards,
Martin

>> Auto-close seems reasonable, but 14 days is too short, even if the
    >> submitter can reopen by adding a new comment....

    Stephen> Suggestion: I don't think an unassigned ticket should be
    Stephen> classed as "pending"....

Which, I must apologize, I completely missed since I came late to the party
and all I was doing was reading individual messages as they arrived in my
inbox.  In particular, I hadn't read through the entire chain of messages.
I sent my response thinking we were discussing a new ticket, not one which
had been completely through the mill and was just waiting for the original
requestor (or someone else) to say, "yeah, this is fixed - please close".
Once in the "pending close" state I agree two weeks should be plenty of time
for someone to respond.

So, mea very culpa.  Sorry for the noise.

Skip

Skip Montanaro writes:
 > 
 > Skip Montanaro <skip@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).

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.  Browsing recent open but unassigned
tickets won't show up such auto-closed tickets.

If I recall correctly, basic search (that which most people will use) is
restricted to open tickets.  If searching for a problem they've encountered,
they may well miss that other people are having the same problem.  What's
the extra cost of bumping the auto-close interval to, say, two months?  It
will take awhile longer to fill the pipeline of dormant tickets, but once
filled it will empty at roughly the same rate as a shorter pipeline, right?

Skip

r71050 adds "scripts/close-pending" script, which I am asking Martin to run a
dry-run against the live database so I can verify the results.  At that point it
should be ready to set up as a cron job.

> I would agree in general, but not 100% of people operate this way. For
> example, *I* don't operate this way. I frequently respond to issues a
> week, two weeks, or even a month later. 

Ok, so when you respond, you will have to reopen the issue. No big deal.

> Then I suggest a month ;)

Changing it now is more effort than not changing it. This is bikeshedding.

Regards,
Martin

> Martin v. Löwis <martin@v.loewis.de> added the comment:
>
> So it is up to the reviewer to decide whether setting the state to
> pending is the right thing.

Then it could just be Open and Close states.
What if the issue is Open for more than 14 days.

> I doubt if auto-closing if issue after a 14 day non-activity period is a good 
> idea.

And indeed, we will not do that. What we will do instead is to close the
issue after 14 day non-activity IF THE STATUS IS PENDING.

So it is up to the reviewer to decide whether setting the state to
pending is the right thing.

On Wed, Apr 1, 2009 at 21:24, Senthil
<metatracker@psf.upfronthosting.co.za>wrote:

>
> Senthil <orsenthil@gmail.com> added the comment:
>
> I doubt if auto-closing if issue after a 14 day non-activity period is a
> good
> idea. The good way to analyze this change is, looking at the current issue
> tracker and seeing how many of the tickets have non-activity beyond 14
> days. If
> there is a huge number, that would give us an idea of churn it will create.
> This
> churn could be for good or bad. Looking the bad side, if the reporter did
> not
> get anyone in the nosy list,his bug will get lost and he may not care
> again.
>
> My sf.net bugs are open for months.
>
> My suggestion would be to send a remainder email with issue age in
> days,months
> or years to catch attention.

The closing of the issue should catch their attention. And commenting will
re-open it so it isn't hard to change the state. I still think that closing
a pending issue after 14 days is a good idea.

I doubt if auto-closing if issue after a 14 day non-activity period is a good 
idea. The good way to analyze this change is, looking at the current issue 
tracker and seeing how many of the tickets have non-activity beyond 14 days. If 
there is a huge number, that would give us an idea of churn it will create. This 
churn could be for good or bad. Looking the bad side, if the reporter did not 
get anyone in the nosy list,his bug will get lost and he may not care again.

My sf.net bugs are open for months.

My suggestion would be to send a remainder email with issue age in days,months 
or years to catch attention.

r71035 adds a pending -> open auditor.

Daniel Diniz wrote:
> Should set Stage ('committed/rejected') and
> Resolution ('out of date' or 'invalid'?).

No - whoever sets it pending should already put it into its final state.

> Do you want it to set a Keyword (or
> short note on auto-closing) to make searching for auto-closed issues easier?

Not sure; we should leave it out for now (it should be possible to find
autoclosed by looking for issues that were closed by admin, if necessary).

SF sent a message to all nosy users explaining what autoclose is. This
message got also logged into the regular message list (IIRC). It might
be useful to send a message here as well; if possible, IMO, it should
be a plain email message, not a roundup message that gets a messageid
and associated with the issue. SF's wording is

"""This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker)."""

OK, I'll work on this one later.

A script that searches for pending issues and compares time since last activity
to a config limit sounds simple. Should set Stage ('committed/rejected') and
Resolution ('out of date' or 'invalid'?). Do you want it to set a Keyword (or
short note on auto-closing) to make searching for auto-closed issues easier?

A detector for pending -> open on comment is trivial.

I still want to see automatic closing of pending issues. SF did that with a
message to all nosy users.

The "pending" status is set during triage, in the expectation that the issue
should likely be closed, unless somebody still comments. Addition of a new
comment reverts the status change. Only if there is no follow-up the issue gets
auto-closed.

Implementation-wise, I would recommend to run a cron job.

While this seems simple to implement, IMO the benefit is small and might
surprise/get in the way of tracker users.

Closing as won't fix suggested, will work on a patch if people still want this :)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Georg Brandl <metatracker@psf.upfronthosting.co.za> writes:

> Georg Brandl added the comment:
>
> Is this now implemented? 

No.

>There is a "pending" status, but is the item closed automatically
>after a period of time?

No.

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFG07DBrJurFAusidkRAqyBAKDCbVDElJdLJoigKJElsn6HCmaMGwCfRUI7
7oBf6WgNN6GLvUwpasMY7es=
=F9h9
-----END PGP SIGNATURE-----

Is this now implemented? There is a "pending" status, but is the item closed
automatically after a period of time?

"pending" means that the issue will automatically be closed after a certain
period of inactivity. I'd really like to have this available in the new tracker too.

What is pending to mean? The source-forge article uses it to mean, "We're
waiting for info from the submitter." We have 'chatting' and 'needs-eg' already.

We eventually set it to mean that the developer had fixed the issue but it
wasn't yet in the 'main' branch. I can imagine in the python-dev context it
meaning that it is fixed in SVN but not yet in the latest release. That might be
useful to the release process? Certainly it helps the person looking up a bug.

One of the oddities of the default statuses is that it doesn't say what they
mean. We went for a long time wondering what done-cbb (done could be better) meant.

[Idea transferred here from
http://www.mechanicalcat.net/tech/roundup/wiki/PyTrackerDesign]

 SourceForge? automatically closes pending issues after certain timeout (default
is two weeks after "pending" status is set, configurable by project admin; see
http://sourceforge.net/docman/display_doc.php?docid=24202&group_id=1#pending_autoclosure).
python-tracker could include a script that can be run by cron to do that.

If issue submitter adds a new note within the expiration time, "pending" status
is automatically changed to "open". python-tracker can do that in issue reactor.