ADD automation to close stale issues?

[ttax00]

Since there remains a lot of open issues that are either resolved, or has been created a long time ago with no activity (way back in 2012). Would it be a good house-keeping policy to automatically close those stale issues?

[saethlin]

No. It would be good to have an automation that helps us locate and track issues that have since been fixed or rendered irrelevant. I do a bit of this manually, and I know a small handful of others do as well. It would be nice to be more effective/efficient at this, but I don't know how.

We really shouldn't close issues automatically. Some of them are about really hard problems that take time or frankly nobody has the determination to work out a solution for. And even for other kinds of issues, we aren't running out of space to store them or something, and many people find stale bots very irritating or off-putting. There's no scarcity here, so I don't see the value which would compell us to eat the cost of accidentally closing relevant issues.

[matthiaskrgr]

We could have some kind of close_it label and once a quarter a triage team reviews the tagged issues and either removes the label, pings the authors or closes the issue or so? (a bit like the triage team for prs?)

[Rageking8]

@rustbot label +A-meta

[jruderman]

There's an automation called Glacier to notice when ICE bugs are unexpectedly fixed.

[ChrisDenton]

Even then it may be better to close the issue by adding a test rather than automatically. That way we prevent unexpectedly regressing the unexpected fix.

[matthiaskrgr]

As for this ticket, we could just wait a year, close it for being inactive and call it a day? 🙃

[Dylan-DPC]

Instead of adding the label, the person looking at this issues can bring it to the notice of the triage team or the respective teams and we can handle them directly instead of having to search for the issues marked with the corresponding label

[ttax00]

I think I should've made the intention for this issue clearer instead of questions. Which admittedly is confusing 😅.

• While I do agree that some issues are really hard problems that take time, it'd be hard to argue that the majority of the 2/3rd of the 8000+ issues (which are +1 years old) are really important.
• Leaving out-dated issues open has their cost on top of storing, just the fact that we'd need someone to skim through 6k worth now-and-then is not sustainable.
• And long issue lists dilute the important problems, making it harder to track what is being worked on, or if one has been forgotten?

A better way could be to flip the closing issues argument on its head:

• Issues are by default has a lifetime (closing after a year) and make this well known so no surprises.
• Issues that are truly important and should be fix can be tagged long_live (for example) and won't be touched by a bot.

That way we only need to mark the golden eggs, rather than picking hay from the haystack.

[Noratrieb]

I don't see why an old issue shouldn't be around. Just because it's old doesn't mean that it doesn't matter or that it's not a real issue. The visibility problem can be solved using labels like P-high.

[ttax00]

I don't see why an old issue shouldn't be around. Just because it's old doesn't mean that it doesn't matter or that it's not a real issue. The visibility problem can be solved using labels like P-high.

Issues on GitHub feels like open-and-forget unless there's activities within it. I'm clear that I have nothing against old but are still relevant issues.

But I think there are quite a bit more solved, out-dated, or wont-be-fix issues that can just hang around for years if no one closes it and adds no value leaving it open. It might cost you a minute to sort out which issues you're looking for. But 1 minute for 4000 contributors we have as an opensource project, adds up.

And its not like closed issues are deleted, we can also discuss a good and quick way to re-open unintended closure.

[jyn514]

There are a lot of ways I would like to improve the issue tracker, but a stale bot is not one of them. Issues today usually fall into one of a few categories:

1. A tracking issue, made because we documented they're required for new features. These use a template, have their own label, and are generally pretty easy to find. We should leave them open until the feature is stabilized or removed.
2. A regression issue, made either through Crater, someone triaging an existing bug, or the "regression untriaged" issue template. These also have their own label and are easy to find, we should leave them around indefinitely until the bug is fixed.
   • Note here that finding the issue in the first place is sometimes dependent on noticing that an existing issue is actually a regression; this is a real example of something that would be helped by fewer open issues.
3. A normal bug report. These should stay open indefinitely.
4. A feature request. I don't know what to do with these; I'm sympathetic that the issue being open does no real harm, but if there's a feature request open after a year that no one has looked at, it's probably unlikely it will ever be looked at unless the Rust project radically changes its approach to features and triages open issues. See also my summary comment below.
5. A request for help. There are hard to triage because sometimes they're a real bug and sometimes they're not, but nearly often there's a possible diagnostic improvement so we leave the issue open until the diagnostic is fixed. These make up nearly half of all old issues on the repo: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+label%3AA-diagnostics . I'm more sympathetic to closing these after a while, since that likely means there would be few people helped by the diagnostic, but I don't think time is a good criteria for that, we should be encouraging people to leave :+1: reactions on the issue so we know if they hit the same problem.

I want to note a larger problem, which is that the issue tracker is basically a graveyard right now. @TechTheAwesome is correct that no one is looking at old issues unless they're labeled somehow, and even the ones that are labeled rarely see activity; consider for example how long even P-high issues normally stick around after being opened: https://github.com/rust-lang/rust/issues?q=is%3Aissue+label%3AP-high+-label%3Aregression-from-stable-to-nightly+-label%3Aregression-from-stable-to-stable+-label%3Aregression-from-stable-to-beta+-label%3Aregression-untriaged+is%3Aopen. Issues that are opened by team members get more attention, but even those often get forgotten unless the author regularly checks in on them. People who aren't part of the project and don't know who to ping or where else to look for help are essentially left out in the cold unless someone happens to notice and label their issue.

I'm not saying a stale bot is the answer, but there is a real problem here; when I joined the project there were less than 3k open issues and there are now more than 8k.

I think this would be useful to track the same way we track PRs; I asked about that on Zulip: https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/issue.20tracking.20stats.20.23103037

[Dylan-DPC]

I feel this is more due to the fact that finding the state of an issue and if any work is pending, is a difficult task for people to spot and pick to work on, even though the work involved isn't complicated.

It does feel bad seeing the number of issues grow, but i feel that's a natural growth of most repositories and with number of contributors not growing at the same rate.

A tracking website would definitely help

I wouldn't close feature issues after a year and those are good to work on even later.

[alice-i-cecile]

So, here's another way to frame this question:

• who has power to close issues?
• what process do they use to determine if an issue should be closed?
• how can we grow and empower that team?

For example, I'd like to get involved in casually contributing to Rust in a project management capacity. However:

1. https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md doesn't have the answer to any of those questions.
2. I have no idea who on Zulip or related platforms has authority to actually answer these questions.
3. The only process docs in the rustc-dev-guide focus entirely on features and bug fixes.

Based on my experience in other projects, I'd close this issue out as Won't-Fix, due to the community consensus against it (and my own judgement). But again, I have no good way to figure out how to get this power, or who to ask to do this on my behalf.

[jyn514]

• who has power to close issues?
• what process do they use to determine if an issue should be closed?
• how can we grow and empower that team?

Anyone in the rust org can, but it's very unclear who should. For a while in 2020 I went around closing random issues that didn't seem relevant and no one complained, but I was never formally given permission, and it wasn't organized with a team or anything like that.

[Dylan-DPC]

@alice-i-cecile you are more than welcome to join the triage team which carries out some of this work (mostly [ at least in our full capacity which isnt at the moment] mostly deals with PRs but also issues)

[alice-i-cecile]

Thanks, I will :) Those broader challenges stand (c.f. my RustConf talk about automation in project management), but this is a good place to start.

[Rageking8]

Can rustbot be used to close issues? If not maybe that can be a new feature to add. Then a few people may be given access to that feature to help close issues that are provably fixed and require no further actions or other off-topic issues. In hopes of reducing clutter in the issue tracker. Not sure if this is any good.

[Dylan-DPC]

If we allow rustbot to do that, I would be wary of people closing issues that are not supposed to be

[Rageking8]

In that case, maybe the original idea of letting people add specific labels to issues that require closing (e.g. #80070) or further action to bring attention to triage members may be better. But this adds work load to triage members.

[alice-i-cecile]

I'd be interested in a "proposed to be closed" label, especially if it was accompanied by clear public guidelines on when to close issues.

[Rageking8]

Maybe we can start off by adding a new label like S-fixed (or some other better wording)(which people can add using rustbot). Then team members can check up on issues with those labels periodically to close them if appropriate.

This can maybe start off as a pliot for a short period of time to see if it works and team members can decide if this is worth it or not.

Other labels such as "further action needed"/"needs fixing" may be added in the future if necessary.

[alice-i-cecile]

S-unactionable is another good candidate :)

[jruderman]

It's one thing to close years-old bugs that will clearly never become actionable. A needs-mcve issue only provides 10 lines from a secretive company's internal tool, the reporter has retired, and the relevant part of the compiler has been refactored twice since then? Sure, that's a candidate for closing.

But in general, reports shouldn't be closed just for being "stale". That defeats the purpose of using a bug tracker. Searching among known, unfixed bugs is a key part of many workflows. Reporters want to avoid filing dups; developers seeking to stabilize a feature want to know whether anything is wrong with it; many types of contributors want to find things they can help with. Having to include closed bugs in these searches would be painful, and much worse than the problems supposedly addressed by a stalebot.

[Rageking8]

Hence, we should not close stale issues but only fixed, off-topic or duplicate issues (presumably manually, as a stale bot is a no no)?

[saethlin]

"stale" just isn't a thing in a project like Rust and possibly any project. There are many useful ways to categorize issues, and those have been laid out above. If you have a bot that can help categorize issues based on content instead of just time open, please do share.

[jyn514]

I'm going to close this; as stated above there are good reasons to close unfixed issues, but age is not one of them.

This is for nils: Closing this issue as it is stale