Do we have interest in trying out the "stale issue" GHA? https://github.com/actions/stale By default (but configurable): • Add a label "Stale" on issues and pull requests after 60 days of inactivity and comment on them • Close the stale issues and pull requests after 7 days of inactivity • If an update/comment occur on stale issues or pull requests, the stale label will be removed and the timer will restart

I think it could be useful, but with significantly increased timeframes.

Hmm, we do routinely have issues open for a very long time that are still active/pending, so the "stale" label would be very helpful (helps us find such issues) but closing such issues is probably not what we want.

@happy-kitchen-89482 We can tag those with special labels and they'll be exempted: https://github.com/actions/stale#exempt-pr-labels

We won't know in advance which those are. I think we really don't want issues closed automatically, but labeled automatically seems like a great idea.

So the workflow would tag the issue first, in which case we could then add the "dont close me" tag. Also issues can always be re-opened 😉

Again, we won't know to re-open them, because we currently assume that closed means closed, and that is a good assumption

Yeah, I like the messaging of "stale" meaning "needs eyes on whether this can be closed". Flagging those automatically is useful. But I'm more wary of automated decisionmaking.

Rust used/uses(?) a low pressure weekly triage email for this sort of thing: https://github.com/graydon/triage/blob/master/send-triage-email.py The script would find the least-recently-updated issues and then email a (self-nominated) number to any one interested (again, self nominated). This helped with controlling the long backlog of issues (https://github.com/graydon/triage/blob/273a799ce14fc748e6de98f0f40234a9524c0ced/send-triage-email.py#L75-L97 spells out what was expected) without leaving people frustrated with the automated stale closure. This is potentially something that could be done via GHA, although I think it's important for the "assignment" to be private (e.g. emails, rather than literal assignment on GH), to keep the pressure low: if someone doesn't get to an issue one week, it'll naturally roll into the next week and be sent to someone else. (Sorry if you've read this already, duplicated from the transition planning doc.)

I think the email for old issues is a good idea. I think the manual triage is important, and this enables that in manageable chunks. I was also going to suggest that we look at old MRs: if they're left open they can quickly diverge and it feels bad for contributors to have their work go to waste through drift. (I'd volunteer to do this, there are only like 80 ) I agree that the auto-close bot can be frustrating. I think it makes sense for support-style issues, where it's unclear whether it's a bug or a usage problem.

Cool. So some consensus around marking them stale it seems? Any thoughts on how long that would need to be

I'd be happy with (automatically) labelling PRs

stale

, but not so much on an issue: It doesn't seem like it brings much value for a manual triage process (sorting from oldest to newest is enough, whether or not they've got a stale marker... and adding the stale label will change the timestamps...), and having it in a label doesn't seem like it communicates much other than potentially annoying people?

90% of our issues are <30 months, 75% are <18 months, 50% are <12 months. If we set the cutoff at 24 months we'd have about 150 issues

Timestamps are kinda the problem though. When I was trying to manually triage, issues where the label changed are "newer" than issues filed later but haven't seen comments. So maybe it's worth checking out if "activity" means comments, in which case I think that's exactly what I want to do. Periodically cull the stale issues.

If it's a valid request, I see nothing terrible about leaving it open as long as it's marked as a request, not a bug. If we had 500 open bugfixes, judge us. But I strongly suspect the main out outcome of closing valid requests without either filling them or marking them wontfix would be that someone else comes along and opens a new issue with the same request. That just creates extra work for the maintainers and disperses discussion across several similar tickets. I empathize with the concern about overwhelming people but there are ways to keep an issue tracker in check. Are stale tickets tagged adequately and accurately? Is the good-first-issue tag being used enough? Are we recruiting and supporting enough nascent Contributors? Is the issues template screening out low-quality requests? Are the authors of stale issues being asked periodically whether they still need this? This old post by Steve Klabnick details how he closed around 350 of 800 open issues, and I still appreciate the methodical nature of it. https://steveklabnik.com/writing/how-to-be-an-open-source-gardener

I haven’t read the conversation yet… But I hate the stale bot in most repos. It results in lots of “shut up bot this issue is still valid” comments.

Interesting strategy!