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

[Uwe Rathmann]

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.

( There might be other good reasons closing these bugs, but waiting for
more info is definitely not the case )

I guess my bugs are not the only ones and if you don't want to lose a lot
of valuable reports this way better stop an revert this bulk changes.

Why should anyone continue reporting bugs, when all what happens is, that
they are put on hold and finally closed automatically ?

Uwe

[Kai Koehne]

-----Original Message-----
project.org> On Behalf Of Uwe Rathmann
Sent: Monday, November 19, 2018 4:10 PM
Subject: [Development] automated bulk change closing old issues in the "Need
more info" state
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.

Then it's good that the bot pointed the wrong state out. Please move the bugs
back to open state (as you apparently did already). Next time you answer,
consider clicking "Provide missing info", instead of just commenting [1].

( There might be other good reasons closing these bugs, but waiting for more
info is definitely not the case )
I guess my bugs are not the only ones and if you don't want to lose a lot of
valuable reports this way better stop an revert this bulk changes.
Why should anyone continue reporting bugs, when all what happens is, that
they are put on hold and finally closed automatically ?

Don't shoot the messenger 😊 Your bugs where in a 'need more info' state,
which a lot of searches exclude, and might have therefore gotten less attention.
If you have a bug in the 'Need more info" state and it's unclear to you what
information is missing, just ask.

Kai

[1]: I agree that the workflow is suboptimal there, but that's apparently what JIRA offers.

[Christian Kandeler]

On Mon, 19 Nov 2018 16:01:32 +0000

Post by Kai Koehne

-----Original Message-----
project.org> On Behalf Of Uwe Rathmann
Sent: Monday, November 19, 2018 4:10 PM
Subject: [Development] automated bulk change closing old issues in the "Need
more info" state
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.

Then it's good that the bot pointed the wrong state out. Please move the bugs
back to open state (as you apparently did already). Next time you answer,
consider clicking "Provide missing info", instead of just commenting [1].

The fact that this is not done ~90% of the time indicates a UI/workflow problem, does it not?


Christian

[Shawn Rutledge]

Post by Uwe Rathmann
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.

[Elvis Stansvik]

Post by Shawn Rutledge

Post by Uwe Rathmann
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.

Maybe some standard reminder about the "Provide Missing Info" button
could be added when the issue is first put into "Need More Info"
state? If the info is there as part of the normal comment flow, the
one making the followup comment with more info would see it I think
(Not sure to what extent that could be automated though).

Elvis

Post by Shawn Rutledge
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development

[Uwe Rathmann]

Post by Shawn Rutledge
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.

In the case of my bugs: in one of them it is totally unclear what
additional info is required or who is the one who should provide more
info. The only thing that seems to be clear is that it is not me, who is
asked.

In the other case setting the "need more info" state looked more like
playing ping pong with the reporter ( = me ). Nevertheless I tried my
best to answer, but was not aware of having to hit an extra button.

But both bug reports have at least been looked at. I have others with
much higher importance, that have been prioritized and assigned once and
then - silence forever.

Uwe

[André Pönitz]

Post by Shawn Rutledge
[...]
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?

Right.

Having to press that button is completely unintuitive for a reporter,
especially after one has been told to not overstep one's competences
by e.g. change priorities of bugs.

Post by Shawn Rutledge
So maybe that button should be (repeated?) at the bottom left.
But I doubt we can customize our Jira to that extent.

A possible solution would be some automated state transition off "Need
more info" once any comment had been added. At least that is a good
first approximation that is more often right than wrong. And maybe "Need
more info" should be used only when running into actual trouble when
reproducing a bug, not as first line of defense for any bug. One could
e.g. ask for more potentially useful but not exactly necessary info
without setting "Need more info".

Andre'

[Alex Blasche]

-----Original Message-----
project.org> On Behalf Of André Pönitz

...

A possible solution would be some automated state transition off "Need more
info" once any comment had been added. At least that is a good first
approximation that is more often right than wrong. And maybe "Need more
info" should be used only when running into actual trouble when reproducing a
bug, not as first line of defense for any bug. One could e.g. ask for more
potentially useful but not exactly necessary info without setting "Need more
info".

That's exactly what's going to happen. This was discussed and agreed upon on this mailing list a while ago. This round of closures was done in preparation of this change. I just wanted to bring the number of issues stuck in NMI down to the not-to-ancient ones and fix the surrounding documentation before I enable the automation later this week.

Time limits will be 2 wks for first reminder and after 2 more wks the bug will be closed. A comment from anybody but the assignee will trigger the automatic return of the task from NMI to "Reported".

https://wiki.qt.io/Jira_Automation

[Alex Blasche]

-----Original Message-----

project.org> On Behalf Of Shawn Rutledge
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.

This filter is limited in scope. It considers only tasks which have been updated within the last 14 days. Naturally this causes bugs to drop out over time. I don't think this is a problem once the automation is enabled.

Note that the level of NMI issues was 2.5k at the end of September before I dropped it to ~700 (nothing older than 1 year since update). This round halfed the number again. The remainder is no older than 20wks. This is was I intend as seed for the automation.

Note that I am on watch on all those issues. People just have to comment with reasonable explanation and I reopen.

[Volker Hilsheimer]

Post by Uwe Rathmann
I guess my bugs are not the only ones and if you don't want to lose a lot
of valuable reports this way better stop an revert this bulk changes.

I understand that the “need more info” -> auto-closing bot workflow is to some degree a bit of a probe to see if someone still cares. It certainly isn’t a greatly named state for that purpose (and one should expect a comment when a bug is moved to that state), but that aside, I’m curious:

When do you consider a bug report “lost”?

JIRA doesn’t forget the bug report. It’s still there, will show up in your searches for “stuff I reported and that wasn’t fixed”, and you get notified when something changes. Perhaps it gets closed as “won’t do” or some other not-fixed resolution because the assignee or maintainer or The Qt Company decides that they are not going to fix the issue (for whatever reason; "corner case”; "too risky to change the code”; “not something we will ever prioritise”).

For a bug report that’s been open for a long time, probability that it results in real action is perhaps going down rather than up the longer you wait. So, leaving it in a “I’ll fix this when I get to it” kind of state is rather not helpful. When it’s closed as “won’t do” etc, at least you know what to expect, and that it’s probably going to be worth your time to develop a workaround or dig into the code yourself to see if you can come up with a fix.



Cheers,
Volker

[Uwe Rathmann]

Post by Volker Hilsheimer
I understand that the “need more info” -> auto-closing bot workflow is
to some degree a bit of a probe to see if someone still cares.

A bug is a bug and if the one who has reported it has lost the interest
in it months/years later - usually because not working on the project
anymore - should not matter.

But maybe the mentality of a commercial product is different than mine.

Post by Volker Hilsheimer
When do you consider a bug report “lost”?

When bug report does not end with a conscious decision of a developer.

Post by Volker Hilsheimer
So, leaving it in a “I’ll fix this when I get to it” kind of
state is rather not helpful.

If the state would be true, I don't have a problem with it. But I can't
remember any bug report, that ever left this state after being there for
longer than - let's say 2 weeks.

Actually I already stopped reporting bugs in areas, where you end up with
assignees, that are known as a pseudonym for /dev/null.

F.e the QPA/EGLFS stuff is full of problems, when working with multiple
touch screens. But obviously this is a rare combination and the Qt
Company seems not being interested - or lost the competence - in fixing
it.

Uwe

[Shawn Rutledge]

Post by Uwe Rathmann
F.e the QPA/EGLFS stuff is full of problems, when working with multiple
touch screens. But obviously this is a rare combination and the Qt
Company seems not being interested - or lost the competence - in fixing
it.

I’m interested in having it work some day, because the inconvenient means of configuring that (by writing JSON files ahead of time) is holding up one of my spare-time projects. But, I’m interested in too many things, and also don’t know exactly what to do about that issue right now, since I’m lacking some experience that others have with trying to support specific embedded systems.

I think ideally it should be auto-configured somehow when possible. That might involve a database of known touchscreen monitors, but we should get that from a third party, not maintain it (just like there are databases with EDID info, USB IDs, PCI IDs and such things). Maybe it already exists? But there also needs to be API for dynamically configuring the screen-to-touchscreen mapping, and saving and restoring known-good configurations when the auto-configuration goes wrong.

Since QTouchDevice is public and does not inherit from any common device class, I figure getting the API right is a Qt 6 task. I want to have a device hierarchy so that devices in general can be associated with each other (associating screens and touch input devices is just one case, but probably there will be others).

Presumably the Plasma project has the same problems with wanting to dynamically configure hotplugged screens (some of which might be touchscreens). I don’t even know the status… since Plasma on Wayland is still unstable even now, AFAICT. (I wouldn’t be surprised if that’s our fault too.)