It has recently been suggested that a cron job automatically closes all issues with the status 'active (needs more info)' and where the last update was made over two weeks ago.

I would like to
1) say why this feature is not necessary.
2) propose a better solution.

1) It is not necessary to close such issues. They are by default invisible to the developers. They are not listed on the issue queue: they are hidden much like "won't fix" and "closed" issues are hidden. They are not usually counted. When one says there are 10 pages of issues, it does not include them.
So, closing them won't make any difference to the developers. This feature is also completely irrelevant in the context it was proposed (dev discussion about RTBC, our workflow and avoiding frustration).

However, some of the "need more info" issues have valid information in them. Closing prematurely is a shame.

2) One should remember from whom we need more info: from the initial reporter, the node author.
So, somewhere on the user page, there should be a section, or even a tab where the user (the author of the issue nodes) can see a list of her issues marked as "need more info". If the user no longer visits d.o., then the issue can stay hidden in the queue: nobody sees it so it does not disturb. If she still visits regularly, the list on her user page will remind her of those issues. She may then go back and say "Sorry folks, I got it sorted out. It was...", or provide more information that would help uncover what could be a real bug.

Comments

aclight’s picture

aclight commented
Status: Active » Postponed (maintainer needs more info)

Your argument in #1 is not true right now, though it might have been the case when you originally wrote this. On d.o at least, active (needs more info) is one of the statuses in the default query, so is displayed on project issue listings by default.

But I agree with your position that automatically closing these issues is a bad idea.

For the second part of this, users already see active (needs more info) issues in the My issues listing at project/issues/user, so I don't see how what you've proposed is any different than that. Maybe you meant there should be a separate listing of ONLY issues marked as active (needs more info). I'm not sure about how useful that would be. Or, again, maybe when you wrote this active (needs more info) was not in the default query and so those wouldn't have been shown at project/issues/user.

So, to be slightly ironic, I'm going to set this to active (needs more info) to ask you to explain what you're proposing in a bit more detail.

beginner’s picture

beginner commented
Status: Postponed (maintainer needs more info) » Active

Yes, my argument #1 is no longer true. It used to be that those issues were not listed by default. The d.o. settings have changed, since.

re. #2, I wrote: One should remember from whom we need more info.
The original purpose of the status was to allow the developer to ask for more info from the user (the person who created the issue).
Unfortunately, the name is not clear, and I've seen users who set the status as "needs more info" because that's what they perceive their own needs to be: they want more info from the developer!

This is an important point. In the context of this very issue, understanding who is supposed to provide more information is the crux of the matter. So, the ambiguity of the status name should probably be solved, too.

So, under the understanding that the status means we need more info from the user (the node issue author), my argument was it would make sense to make a list of such issues much more prominent somewhere for the user to see. Thus, when they log in, they see a list of issues where their feedback is required. This is important, because they are the ones blocking a proper resolution of the issue.

So yes, I mean a separate listing of ONLY issues marked as active (needs more info), maybe in a block (so it's visible everywhere and won't be missed). To complete the ironic streak, I didn't see aclight's reply up until right now. For some reason, I have not received an email notification either. Had a block appeared for me on Drupal with this issue requiring my follow up, I would have replied much earlier.

The block would also explain WHO is supposed to provide more information, decreasing the current users' misconception of what this status means.

Under such conditions, those issues wouldn't need to be listed by default in the whole listing.

Another possibility would be to completely remove this status, but add a new field: needs more info from.... together with an autocomplete field to input a comma separated list of user names. Thus we could require more info from more than one user who may have participated in the thread.

aclight’s picture

aclight commented

@beginner: The fact that you didn't receive the issue follow up email was due to a bug in project_issue that's since been fixed, so at least that's not a permanent problem.

beginner’s picture

beginner commented

Ok, thanks for the info.

arlinsandbulte’s picture

arlinsandbulte commented

Looks like this has changed between now and then:
status in question is now "Postponed (maintainer needs more info)"

IMO, I like the suggestion to close out issues which sit at "Postponed (maintainer needs more info)" for a lengthy time with no reply or activity.
Here is what I propose:
If an issue has no activity for 2 months with a state of "Postponed (maintainer needs more info)," automatically change status to "Won't Fix".

This will help keep the issues queues cleaner and more manageable.
Abandoned issues will get removed from the 'active' list.
Issue creators/supporters will be forced to provide more/better supporting information to the maintainer to keep it alive.
Valid issues can/should be resurrected (with additional supporting information as requested).

What do you think?

arlinsandbulte’s picture

arlinsandbulte commented
Title: Dealing with "active (needs more info)" issues » Dealing with "postponed (maintainer needs more info)" issues
Version: 5.x-2.x-dev » 6.x-1.x-dev
sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Status: Active » Postponed (maintainer needs more info)

Huge -1 on this proposal. Very often, users do not change the status when replying to a postponed (needs more info) issue, so you can scratch your statistics. And sometimes it's even good that most users don't do that, because it can easily turn into an epic status change for every single reply on the issue until the concrete issue/problem has been clearly identified.

Won't fix for me.

arlinsandbulte’s picture

arlinsandbulte commented
Status: Postponed (maintainer needs more info) » Closed (won't fix)

OK, so it seems this has limited support. I'm ok with that.

The issue queue guidelines allow the reviewer/maintainer to do as they please anyway:
http://drupal.org/node/156119

Postponed (maintainer needs more info)
There is insufficient information in the issue to proceed. Should no additional information about the issue be provided, the issue may be marked either "closed (cannot reproduce)" or "closed (won't fix)" at the discretion of the reviewer.

As for me, I plan on manually marking most "Postponed (maintainer needs more info)" issues closed if there is no relevant feedback for more than two months, on my own discretion.
I agree, not every "needs more info" issue should be closed.

catch’s picture

catch
he/him
Primary language English
commented
Status: Closed (won't fix) » Active

Coming here from #1230642: Automatically mark "postponed (maintainer needs more info)" issues to "closed (cannot reproduce)", I would really like to do this - I often see issues that were crappy bug reports, marked 'needs more info', then never updated again for two years.

Two months (could even be longer) seems fine to me. It doesn't need to be quick, but there is a point where an issue in that status ceases to be active in any sense of the word.

xjm’s picture

xjm
she/her
Primary language English
commented
Priority: Minor » Normal

This would be a very useful feature, actually. I think the key thing would to have an auto-comment with a helpful, polite message explaining how and when to reopen the issue.

Edit: Also, it would be important to do 2 months from the latest comment, not from when the status was set. That's the pattern we use for fixed issues anyway.