# Moving stale "Waiting on author" Trac tickets into other queues **URL:** \ **Category:** Website\ **Created:** [July 29, 2026, 6:39am UTC](https://forum.djangoproject.com/t/moving-stale-waiting-on-author-trac-tickets-into-other-queues/45617 "2026-07-29T06:39:26Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![smallsaucepan](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/smallsaucepan/32/31265_2.png) [@smallsaucepan](https://forum.djangoproject.com/u/smallsaucepan)\ **Post date:** [July 29, 2026, 6:39am UTC](https://forum.djangoproject.com/t/moving-stale-waiting-on-author-trac-tickets-into-other-queues/45617/1 "2026-07-29T06:39:26Z")
Noticed in the “Waiting on author” queue there are quite a few issues not been touched for more than 3 years (15+ for a couple). Some have had the author not respond, got put on hold due to a feature freeze way back when, or had the PR closed and the _patch needs improvement_ flag left set. Would it be out of line to suggest revisiting some of these to get them into a more appropriate queue? Understand not wanting to discourage an individual still working on a topic. Couple of years inactivity seems safe enough a buffer though, and they’re topics that might pique the interest of a new contributor. Some examples: 1. [#34392 (Allow using test client response.json() with StreamingHttpResponse) – Django](https://code.djangoproject.com/ticket/34392) - 3 years idle, _has patch_ and _needs tests_ set though no sign of patch or PR 2. [#32640 (Non-manager instance assigned to model class' objects is silently ignored) – Django](https://code.djangoproject.com/ticket/32640) - 5 years idle, _patch needs improvement_, PR closed 2022 due to lack of activity 3. [#21523 (Models DateField to\_python method no longer supports mock dates.) – Django](https://code.djangoproject.com/ticket/21523) - 10 years idle, _patch needs improvement_, PR closed 2016 by author 4. [#8972 (Add ability to delete selected vector features within the Geodjango/OpenLayers Admin map interface) – Django](https://code.djangoproject.com/ticket/8972) - 15 years idle, 18 year old patch to file that doesn’t exist any more, sidelined due to 1.2 feature freeze Maybe issues like 1-3 we clear flags and owner to put back into “Needs patch” queue? Tagging the most recent author in the PR as a courtesy. And those like 4 go back to “Needs triage” given it’s been so long since they’ve been looked at? Thanks James ---
**Author:** ![jacobtylerwalls](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/jacobtylerwalls/32/30603_2.png) [@jacobtylerwalls](https://forum.djangoproject.com/u/jacobtylerwalls)\ **Post date:** [July 29, 2026, 4:52pm UTC](https://forum.djangoproject.com/t/moving-stale-waiting-on-author-trac-tickets-into-other-queues/45617/2 "2026-07-29T16:52:43Z")
If you notice there’s not a patch at all, please do clear that flag. But if there is a patch and it’s old, there can be value in leaving that flag set, because folks might like to choose to iterate on things that were already started. (Or on the contrary, folks might prefer to start greenfield rather than catch up with a long conversation on the prior attempt.) “Waiting for author” doesn’t mean waiting forever, of course. ---
**Author:** ![tom](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/tom/32/6818_2.png) [@tom](https://forum.djangoproject.com/u/tom)\ **Post date:** [July 29, 2026, 9:26pm UTC](https://forum.djangoproject.com/t/moving-stale-waiting-on-author-trac-tickets-into-other-queues/45617/3 "2026-07-29T21:26:49Z")
I’m a fan of (at least semi-) automating this type of toil, soI like the idea of somehow clearing them automatically after some period of inactivity. It would be nice if the tracker was (roughly) in a correct state and not relying so much on someone happening on an issue - it would then be more useful for filtering to find things to work on, for Djangonaut Space, for myself, whatever. Two questions: - what defines inactivity? 3 months of no activity on the ticket by the assigned user and no progress on the PR… and that PR isn’t waiting for a review… and… the list goes on? - how would we hook this up? it’s possible, I suppose, to have some script somewhere that does this, but the crossing between Trac and GitHub to find all the relevant details is tricky, and even if it were perfect, you can’t rule out false positives. A simpler interim solution might be grabbing a bulk export from Trac. Unfortunately there’s no way to filter on last activity as far as I can tell, but you could presumably vibe code a script fairly easily to go through the tickets, find those that are assigned but have no recent activity on trac, grab any open pull requests, check for activity there, and give you back a shortlist to check manually. Not my idea of fun, though. ---
**Author:** ![jacobtylerwalls](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/jacobtylerwalls/32/30603_2.png) [@jacobtylerwalls](https://forum.djangoproject.com/u/jacobtylerwalls)\ **Post date:** [July 29, 2026, 11:15pm UTC](https://forum.djangoproject.com/t/moving-stale-waiting-on-author-trac-tickets-into-other-queues/45617/4 "2026-07-29T23:15:26Z")
My appreciation of inactivity usually scales with how lucky the author’s been getting a review. Booting someone from a ticket after 3 months after it took 10 months to receive a review is not fair. But after 6 months waiting for a review, if multiple iterations unfolded in a short time, and then 3 months of silence? Maybe that’s inactive (barely). ---
**Author:** ![smallsaucepan](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/smallsaucepan/32/31265_2.png) [@smallsaucepan](https://forum.djangoproject.com/u/smallsaucepan)\ **Post date:** [July 30, 2026, 2:12am UTC](https://forum.djangoproject.com/t/moving-stale-waiting-on-author-trac-tickets-into-other-queues/45617/5 "2026-07-30T02:12:31Z")
Thanks Jacob and Tom. To allay any concerns I’m not in talking about booting anyone at X months and 1 day. This is only about issues with years of inattention and making sure “Waiting for author” is kept meaningful. > [@jacobtylerwalls](#): > > “Waiting for author” doesn’t mean waiting forever, of course. Do you mean contributors already understand they aren’t expected to wait forever and can claim issues from that queue as they do now? Or that we should think about moving them out of Waiting for author when some limit passes? I can read this either way 😅 Taking a step back maybe (and this is going far beyond what I originally had in mind) instead of: Needs Triage | Needs Patch | Needs PR Review | Waiting On Author | Ready For Checkin we had Needs Triage | Needs Owner | Waiting On Owner | Needs Review | Ready For Checkin Makes more use of Owner than Has patch, which un-overloads some of the meaning placed on that flag. It’s a more natural left to right progression, and the escape hatch we’re discussing (Waiting On Owner → Needs Owner) might seem less dramatic. > [@tom](#): > > - what defines inactivity? 3 months of no activity on the ticket by the assigned user and no progress on the PR… and that PR isn’t waiting for a review… and… the list goes on? At least a year? Getting community feedback + fixing without breaking anything + personal circumstances = could easily add up to 12 months. And some of these things will legitimately drag on for years, or maybe never be fixed cause they’re incredibly difficult. However if there is no currently viable patch, Waiting for author doesn’t seem like the right bucket. > [@tom](#): > > - how would we hook this up? > > … give you back a shortlist to check manually Yeah I like that approach. An ad-hoc report is probably the way to go. If the person is still active with Django for example, it’d be worth pinging them on github first anyway. ---
**Author:** ![smallsaucepan](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/smallsaucepan/32/31265_2.png) [@smallsaucepan](https://forum.djangoproject.com/u/smallsaucepan)\ **Post date:** [July 30, 2026, 1:48pm UTC](https://forum.djangoproject.com/t/moving-stale-waiting-on-author-trac-tickets-into-other-queues/45617/6 "2026-07-30T13:48:30Z")
Continued to explore this during the day, trying out different report criteria with the fields we have: - Needs Triage - triage:unreviewed and not status:closed. Lets reporter assign themselves as owner if need be - Needs Owner[1] - triage:accepted and status:new. Ignores other flags including has patch, patch needs improvement, etc. They stay as they were in cases where an issue is coming back to Needs Owner from Waiting On Owner - Waiting On Owner - triage:accepted and status:assigned and (no patch or has patch and patch needs something). This would include issues that previously got a patch by the owner, got unassigned due to inactivity, kept the flags, and then eventually has someone else pick it up - Needs Review - triage:accepted and status:assigned and has patch and patch needs nothing. Basically the same as now except we exclude new Don’t think there’s any gaps I’ve introduced. This way we could keep Has patch to mean “has ever had a patch”, letting people filter as Jacob suggested. If a ticket looks like it’s in limbo de-assigning it would put it back into Needs Owner. It would also mean as soon as a ticket has an owner it moves out of Needs Owner into Waiting On Owner. That seems clearer to me as a potential contributor what’s up for grabs and what’s spoken for. Realise there’s been lots of discussion on moving away from Trac, lots of refinement already, etc, so hopefully not covering old ground. [1] Or Needs Patch although that’s not really what the criteria imply any more ---
**Author:** ![CodenameTim](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/codenametim/32/31507_2.png) [@CodenameTim](https://forum.djangoproject.com/u/CodenameTim)\ **Post date:** [August 23, 2026, 10:37am UTC](https://forum.djangoproject.com/t/moving-stale-waiting-on-author-trac-tickets-into-other-queues/45617/7 "2026-08-23T10:37:17Z")
> [@smallsaucepan](#): > > Don’t think there’s any gaps I’ve introduced. This way we could keep Has patch to mean “has ever had a patch”, letting people filter as Jacob suggested. If a ticket looks like it’s in limbo de-assigning it would put it back into Needs Owner Would it be helpful to have a report that includes all the tickets that may be stale? That queue should effectively be for the review and triage team to go through and ping the owner to determine if it should still be assigned or to unassign them. The concept of vulturing a ticket is a bit weird because it’s still assigned to someone. If we can keep the tickets fresh from an assignment perspective, we remove that peculiarity. ---
**Author:** ![smallsaucepan](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/smallsaucepan/32/31265_2.png) [@smallsaucepan](https://forum.djangoproject.com/u/smallsaucepan)\ **Post date:** [August 24, 2026, 2:18am UTC](https://forum.djangoproject.com/t/moving-stale-waiting-on-author-trac-tickets-into-other-queues/45617/8 "2026-08-24T02:18:04Z")
> [@CodenameTim](#): > > Would it be helpful to have a report that includes all the tickets that may be stale? Would certainly make life easier for cleaner-upperers. It should probably include some aspect of related PR statuses? Not just rely on timeframes. > [@CodenameTim](#): > > The concept of vulturing a ticket is a bit weird because it’s still assigned to someone. Well, yes and no. People are bound to drift away without necessarily tidying up on their way out. For an open source project that takes its time … that’s showbiz. Despite what our records say that person likely hasn’t thought about it in years. > [@CodenameTim](#): > > If we can keep the tickets fresh from an assignment perspective, we remove that peculiarity. Note though clearing the assignment doesn’t currently change much. Tidying up the assignments is good housekeeping, except the queue each ticket appears in hinges almost entirely on “has patch”. Hence the suggestion to base the queues more on Assigned. That might lessen apprehension among new contributors if Trac has one all encompassing list of tickets that need someone to take them on. Less guesswork. ---
**Author:** ![alexanderamoreau-gli](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/alexanderamoreau-gli/32/33176_2.png) [@alexanderamoreau-gli](https://forum.djangoproject.com/u/alexanderamoreau-gli)\ **Post date:** [August 25, 2026, 2:56pm UTC](https://forum.djangoproject.com/t/moving-stale-waiting-on-author-trac-tickets-into-other-queues/45617/9 "2026-08-25T14:56:51Z")
I don’t think that would be out of line. After 3 to 5 years of inactivity, the current status can become misleading, especially when an old patch or closed PR leaves the ticket sitting in “Waiting on author” with no realistic sign that anyone is still working on it. I like the idea of treating the different cases differently rather than moving everything automatically. Clearing the stale flags on something like 1-3 and putting them back in “Needs patch” seems reasonable. For something as old as 4, “Needs triage” sounds more appropriate since the original patch is no longer useful. Tagging the last contributor first also seems like a fair courtesy. If there is no response after a reasonable period, moving the ticket should make the queues easier to work through and might give new contributors something useful to pick up. ---
**Author:** ![CodenameTim](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/codenametim/32/31507_2.png) [@CodenameTim](https://forum.djangoproject.com/u/CodenameTim)\ **Post date:** [August 25, 2026, 10:39pm UTC](https://forum.djangoproject.com/t/moving-stale-waiting-on-author-trac-tickets-into-other-queues/45617/10 "2026-08-25T22:39:57Z")
> [@smallsaucepan](#): > > That might lessen apprehension among new contributors if Trac has one all encompassing list of tickets that need someone to take them on. Less guesswork. Cool, we’re on the same page here. 😁 > [@smallsaucepan](#): > > Tidying up the assignments is good housekeeping, except the queue each ticket appears in hinges almost entirely on “has patch”. Hence the suggestion to base the queues more on Assigned. That makes sense to me, but I would suggest naming the queue to be the action needed rather than the object needed. What is an owner to a new contributor? Can we name that queue to be clearer that’s where someone should look to contribute code? That way it matches Needs Triage and Needs Review and Ready for Checkin.