#19 RFE: "Snooze" items for a specified amount of time
Opened 2 years ago by decathorpe. Modified 2 years ago

For a packager like me (with hundreds of packages) the dashboard is cluttered with issues that are not actionable, because they just cannot be resolved at this point in time. it would be very useful to be able to say "don't show this item for $Duration" (maybe with three options: one week? two weeks? a month?)

Maybe the "don't show this information until $timestamp" information can be stored locally in a cookie or something like that?


First of all, thanks for the feedback!

Let me take this a bit further by asking a question back - do you think there is a way of detecting the "unactionable" issues automagically? Maybe you'd be only interested in bugs in specific states? What are you typically looking at, when deciding whether an issue is actionable, or not?

I'm asking because I guess this would be similar for more people, and if we could come up with some "sane defaults" that would be awesome for us too.

Also, about the postponing - is the "let's review the issue" necessarily time-bound, or do you thing there would be consistent factors that play a role in deciding that it makes sense to revisit an issue? Maybe when new comments are added, or the state of the bug is changed?

Anyway, I think that having an UI option to "hide" elements for specified amount of time is doable, but as I said earlier, I'd love to take this a bit above "smashing the annoying blinking light" to "maybe not show what's not necessary".

Thanks!

First of all, thanks for the feedback!

Sure! I've used the test instance for a bit, and it's already been useful, so I'd like to see this succeed :)

Let me take this a bit further by asking a question back - do you think there is a way of detecting the "unactionable" issues automagically? Maybe you'd be only interested in bugs in specific states? What are you typically looking at, when deciding whether an issue is actionable, or not?

I have three examples for this:

  • FTBFS issues from koschei
  • FTI issues from fedora-health-check
  • "new version available" bugs from anitya / release-monitoring.org

For RHBZs that are blocking the FTI / FTBFS trackers, I can actually go in and set the bug to a different state (though I'm unsure which state would hide the bug in the packager dashboard?), but for koschei and fedora-health-check, I can't actually do anything about those data points, if I can't fix the actual problem yet.

Also, "version x.y.z is available" bugs from anitya / release-monitoring.org are often blocked by something else, so the best I can do for them is to change their status from NEW to ASSIGNED, but that won't hide them from the dashboard.

Also, about the postponing - is the "let's review the issue" necessarily time-bound, or do you thing there would be consistent factors that play a role in deciding that it makes sense to revisit an issue? Maybe when new comments are added, or the state of the bug is changed?

It's probably hard to find good heuristics for this, since there are different timelines at play here:

  • orphaned packages get retired after 6 weeks, so you'd probably never want to hide problems related to that for longer than (6 weeks - time since it was orphaned)
  • unaddressed FTBFS / FTI RHBZs (bug status not changed from NEW to ASSIGNED, I think?) lead to packages being orphaned after a few weeks, so you'd probably not want to hide those at all, but poke users to actually change the bug status to ASSIGNED, instead, if they're actually looking into it

Anyway, I think that having an UI option to "hide" elements for specified amount of time is doable, but as I said earlier, I'd love to take this a bit above "smashing the annoying blinking light" to "maybe not show what's not necessary".
Thanks!

Sure, that's a good idea, and for some things, that's probably the better solution, but I doubt that those heuristics can cover "all" cases.

Since the ASSIGNED state in BugZilla is probably the closest thing to saying "I'm already working on this", maybe having a toggle to hide bugs in the this state would be a good start? Something similar applies to bugs in the POST or ON_QA state, which implies that "I've already worked on this, update pending".

Or, maybe optionally hide bugs that are blocked by other, non-closed bugs?

I have three examples for this:

FTBFS issues from koschei
FTI issues from fedora-health-check
"new version available" bugs from anitya / release-monitoring.org

For RHBZs that are blocking the FTI / FTBFS trackers, I can actually go in and set the bug to a different state (though I'm unsure which state would hide the bug in the packager dashboard?), but for koschei and fedora-health-check, I can't actually do anything about those data points, if I can't fix the actual problem yet.
Also, "version x.y.z is available" bugs from anitya / release-monitoring.org are often blocked by something else, so the best I can do for them is to change their status from NEW to ASSIGNED, but that won't hide them from the dashboard.

We are (IMO) not hiding any that are "any kind of open" (correct me if I'm wrong @lbrabec @frantisekz ) ATM, but at least having a filter on "I'm only interested in these states" (maybe with reasonable defaults) sounds like a good idea anyway.

It's probably hard to find good heuristics for this, since there are different timelines at play here:
orphaned packages get retired after 6 weeks, so you'd probably never want to hide problems related to that for longer than (6 weeks - time since it was orphaned)
unaddressed FTBFS / FTI RHBZs (bug status not changed from NEW to ASSIGNED, I think?) lead to packages being orphaned after a few weeks, so you'd probably not want to hide those at all, but poke users to actually change the bug status to ASSIGNED, instead, if they're actually looking into it
...
Sure, that's a good idea, and for some things, that's probably the better solution, but I doubt that those heuristics can cover "all" cases.

Yeah, I guessed there would not be a straight universal answer, but this already looks like we are on a path to "better defaults" at least. Thanks!

Since the ASSIGNED state in BugZilla is probably the closest thing to saying "I'm already working on this", maybe having a toggle to hide bugs in the this state would be a good start? Something similar applies to bugs in the POST or ON_QA state, which implies that "I've already worked on this, update pending".

Makes sense, what do you think @lbrabec?

Or, maybe optionally hide bugs that are blocked by other, non-closed bugs?

Sounds interesting, at least as an option. @frantisekz could you look into that? I'm not sure what data specifically are we getting from Bugzilla ATM, but if we could add "blocked by non-closed bugs" flag to the issues, filtering those on the frontend should be a breeze.

"new version available" bugs from anitya / release-monitoring.org

I've proposed to be able to hide those in https://pagure.io/fedora-qa/packager_dashboard/issue/3

Since the ASSIGNED state in BugZilla is probably the closest thing to saying "I'm already working on this", maybe having a toggle to hide bugs in the this state would be a good start?

Also this, the same link.

Or, maybe optionally hide bugs that are blocked by other, non-closed bugs?

Added this there as well.

Login to comment on this ticket.

Metadata