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.
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.
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.
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).
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.
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.
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.
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.
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
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.
Would certainly make life easier for cleaner-upperers. It should probably include some aspect of related PR statuses? Not just rely on timeframes.
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.
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.
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.
