Posted by grendzy on January 31, 2012 at 10:53pm
10 followers
Jump to:
| Project: | Project issue tracking |
| Version: | 6.x-1.x-dev |
| Component: | Issues |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
In a discussion about min/max thresholds on core rtbc, webchick wrote:
all I have is priority, time since last comment, and total time an issue has been opened, so often these "chronic" issues can fall by the wayside... we don't have a view that shows time spent in the RTBC queue
Exactly how we measure "time in rtbc queue" is uncertain, since sometimes there incidental / accidental status changes that shouldn't count against an issue's queue position, so can we brainstorm on this a bit?
Comments
#1
That's pi functionality.
#2
One thing that might be easier to measure is the age of the last patch on the issue. So if I post a patch, it sits at cnr for six weeks, then gets to rtbc with no modifications, that might be near the top of the queue even though it was rtbced two hours ago. Compared to a patch that was posted 48 hours ago and RTBCed 12 hours ago then had two minor followups posted while the status was left at RTBC.
This goes back to the meta issue, but are we trying to get at both sides of this?
- patches which are a bit green round the ears and might not actually be ready yet.
- patches which have been waiting around a long time.
Either rtbc age or patch age is going to affect these slightly differently.
#3
Didn't think thoroughly through it, but "latest patch age" makes indeed way more sense to me than "rtbc age."
#4
Interesting. "latest patch age" and "view" make me say "denormalize". This will absolutely destroy some already bad queries if we try to figure this out each time via SQL. We need to record a timestamp in a new column in the {project_issue_nodes} table, keep it accurate, expose it to views, and then alter the default views to include a sort by this.
Sorts in Views2 are a bit sucky, since you have to make them columns in a table if you want to have different possible sort orders. We should have a separate issue about upgrading d.o to Views3 and ensuring PI is compatible with that. Then, we could have a bunch of exposed sorts, even if we don't necessarily want to display all these timestamps in the default (or adv search) issue queues.
Then again, if we're sorting by this sort of thing, maybe we need to display it, too. But, that seems pretty specialized. I think a better approach is doing the denormalization and exposure to views via this issue, and then have another drupalorg issue open for a new RTBC view with all the bells and whistles we need for this. Does that make sense to y'all?
Thanks,
-Derek