[Development] automated bulk change closing old issues in the "Need more info" state

Shawn Rutledge Shawn.Rutledge at qt.io
Mon Nov 19 17:36:45 CET 2018


> On 19 Nov 2018, at 16:09, Uwe Rathmann <Uwe.Rathmann at tigertal.de> wrote:
> 
> Hi all,
> 
> I just received 2 messages about: automated bulk change closing old 
> issues in the "Need more info" state.
> 
> - https://bugreports.qt.io/browse/QTBUG-68874
> - https://bugreports.qt.io/browse/QTBUG-66264
> 
> I have no idea why they have been set to "Need more info" - actually one 
> of them has been explicitly answered, but the developer does not follow 
> up.

When you answer the question, you are supposed to hit the “provide missing info” button: that takes it out of that state.

Also, every week we have a team of 2 people triaging bugs.  Part of that job is to check all the bugs that are in “need more info” state, and decide whether the info is now sufficient.  Then it should either be moved out of “need more info” state, or closed.  But it’s easy to ignore that… so I suspect many triage teams aren’t trying very hard to get through those.  Often, the reporter of the bug does not provide any extra info for a long period of time, so it is demotivating to go through the list and just confirm yet again that nothing new was added to most of them.

https://bugreports.qt.io/issues/?filter=16028 currently has 169 bugs in that state.  Having that many is an obstacle: I don’t suppose this week’s triage team is going to get through all of those and make intelligent decisions about them, either. If it was only 10, maybe they would.

So to shorten that list, it helps a lot if you hit the “provide missing info” button when you answer a question.  If the bug does not have a priority and/or is unassigned, then it’s going to get looked at again by that week’s triage team.  If it stays in “need more info” state, it might be ignored for a while because it’s not in the un-triaged list.  Not ideal, but that’s how it’s actually been.

I suspect the reason people don’t hit that button is that it’s at the top, whereas when you add a normal comment, you press the comment button at the bottom.  And if you are actually answering the question with your comment, you assume that’s enough,  right?  So maybe that button should be (repeated?) at the bottom left.  But I doubt we can customize our Jira to that extent.



More information about the Development mailing list