Closing stale issues and PRs automatically

[SimenB]

🚀 Feature Proposal

Hey! 👋

As many have probably noticed, this repository has over 1500 open issues, and 150 open pull requests. I've tried in the last couple of weeks to do something about it, and while PRs have gone down from 200 (plus I've landed many new ones), the issues have been untouched. I've spot checked a few, and about half of them are no longer relevant (either due to old version of node, or just plain fixed in newer versions of Jest).

As mentioned a few times before, this project is 100% community driven, so any time spent is either taken away from work hours (which I've been guilty of the last couple of weeks 😅) or spare time/weekends/holidays. This makes it quite the chore to go through them all, and for the health of the project (and my own mental one), I think getting the number of open issues and PRs down is a good step towards making it easier to stay on top of new ones.

We've started locking old closed issues automatically, and we also have quite good issue templates that have increased the quality of both bug reports and feature requests. Both of these have helped, and I hope closing old stale issues will do the same!

That said, I understand it's frustrating to see your issue or PR you spent time putting together, and which might still be relevant, be closed as stale by some stupid bot. So feel free to provide feedback here in this issue if there's anything in the process we can improve! Just keep in mind there are unpaid humans behind this project (mostly a single human since summer), so if the solution is "get to the issue quicker" or "spend more time", that's not really scalable 🙂

Lastly, thanks for using Jest and reporting issues and sending PRs - I hope that by making the backlog more manageable the project will be easier to maintain going forward!

❤️

---

Lastly, please give the alpha releases of Jest v28 a try! 😀 yarn add jest@next.

[StringEpsilon]

One thing I noticed immediately: The stale bot does not differentiate between types of tickets. I think feature requests should not be closed just because they're old. But marking them as stale might help make the decision to close them, if there wasn't much discussion or work.

This currently affects 184 tickets. Including "Issue triage needed" (11086) :)

Similar categories may be:

• Upstream bug (4 issues)
• Enhancement (6 issues)
• Confirmed (10 issues)

Again: Marking those as stale may aid in evaluating the issues, but I don't think those should be remove automatically.

I also think that maybe 7 days between flagging the issue and deleting it is a bit short. Go on vacation during the wrong time and the issue that still may still affect you gets closed. That's not nice. I'd bump that to 30 days.

Addendum: Another thing I noticed is that there are a lot of labels for issues. Some seem less relevant and useful than others.

[SimenB]

Issues more than a year old get 14 days, not 7. But I get what you're saying - can set them all to 30 days (messages already posted will lie I guess, but no biggie). EDIT: 3a411d1

As for marking feature requests as stale - we could maybe have a separate job for them? If there's been no activity for say 3 months, that just means nobody has the time or inclination to fix/implement it. Keeping them around just to keep them around doesn't make a lot of sense to me?

---

And yes, we have a bunch of labels we should get rid of

[SimenB]

Oh, and if there are specific issues you (or others) think should always be open, feel free to leave a comment here with them and I can add the Pinned label so they're left alone

[conartist6]

What about the github triage permission? Stalebots have their purposes, but Jest is just a huge project and there actually are a lot of issues with it. But there are also a lot of people who would probably be willing to help clean up the mess instead of, shall we say, sweeping it under the rug.

[conartist6]

I'm also of the opinion that jest is in some ways too large to be a monorepo, and in some ways it's still a megalith. The best thing that could happen to it is for some of its packages to become independent, use semver versioning, and have their own communities and systems of trust. They might even start getting documentation!

[StringEpsilon]

If there's been no activity for say 3 months, that just means nobody has the time or inclination to fix/implement it. Keeping [feature requests] around just to keep them around doesn't make a lot of sense to me?

As I said, a feature request being stale is still a valid indicator to look at it again and to consider closing it. But ultimately, it should be a matter of if the feature makes sense for jest. And not whether or not someone bothered to bump it against stale-bot continuously. Some feature requests I looked over also have some valuable discussion and design work already put into them. Good example being number 7163 ("Request to add support for CI/CD pipelines for Test reporting).

I'm also much more likely to +1 a feature request I'd like to see implemented than reopening a closed one. And maybe it's just me, but I also don't bother looking into the exact reasons why a feature request was denied - I just find it via issue search or google, see it closed and give up.

Also, just looking through some of these stale feature requests: A lot of them seem either very fringe (I'd say 7949 and 8274), are arguably out of scope (6383), or the discussion about the usefulness stalled (7090, maybe 7304), which probably why they didn't see much attention. Those can probably be closed for those reasons.

[SimenB]

What about the github triage permission? Stalebots have their purposes, but Jest is just a huge project and there actually are a lot of issues with it. But there are also a lot of people who would probably be willing to help clean up the mess instead of, shall we say, sweeping it under the rug.

I unfortunately don't have the necessary permissions to add triagers, but that would be ideal 🙂 But if people start to triage, even if they cannot close or add labels, that would definitely help out!

I'm also of the opinion that jest is in some ways too large to be a monorepo, and in some ways it's still a megalith. The best thing that could happen to it is for some of its packages to become independent, use semver versioning, and have their own communities and systems of trust. They might even start getting documentation!

I don't disagree, but unless somebody steps up immediately (that we can trust), splitting out packages just adds more work for me. Sorta chicken and egg problem, but it would exacerbate the problem I'm trying to mitigate by adding this bot.

Also, we have extensive integration tests in this repo, which is how many subtly bugs have been caught that unit tests don't pick up. You could say unit tests should be better but... more work again.

This is a big project with many moving parts, and as long as there is essentially only a single active maintainer, keeping it in one repo is IMO the only viable way of maintaining it.

If there's been no activity for say 3 months, that just means nobody has the time or inclination to fix/implement it. Keeping [feature requests] around just to keep them around doesn't make a lot of sense to me?

As I said, a feature request being stale is still a valid indicator to look at it again and to consider closing it. But ultimately, it should be a matter of if the feature makes sense for jest. And not whether or not someone bothered to bump it against stale-bot continuously. Some feature requests I looked over also have some valuable discussion and design work already put into them. Good example being number 7163 ("Request to add support for CI/CD pipelines for Test reporting).

I'm also much more likely to +1 a feature request I'd like to see implemented than reopening a closed one. And maybe it's just me, but I also don't bother looking into the exact reasons why a feature request was denied - I just find it via issue search or google, see it closed and give up.

Also, just looking through some of these stale feature requests: A lot of them seem either very fringe (I'd say 7949 and 8274), are arguably out of scope (6383), or the discussion about the usefulness stalled (7090, maybe 7304), which probably why they didn't see much attention. Those can probably be closed for those reasons.

Yeah, I get where you're coming from, but having a bunch of open issues (valid or not) doesn't really serve any purpose I think. I will personally never look at them and it's very rare they are actually picked up by someone else.

Having an enormous backlog is mentally draining, and only seeing that increase over time makes any time investment feel less worthwhile than it is.

If you want a feature into Jest, the best way will always be to contribute the code needed for it to happen. While I understand the barrier is way higher since you cannot even know if it'd be accepted, I don't know of any other way to keep the backlog relevant. Triagers as suggested above would help of course, so we're only left with high quality issues that we would want to do something about, but we'd need somebody to step up and do that job.

And if the choice is between closing feature requests and bug reports that are valid, but nobody has had the time and/or interest to implement and staying on top of new issues and keeping the project going, I'll choose the latter.

[conartist6]

Yeah I know everyone makes PRs for their own little problem, but that's different than maintainership and, as you note, generally creates more work for you not less.

If the problem is that there's an incredible amount of work that only you can possibly do, then why can't we solve that problem? We are engineers, after all. So what are the barriers to adding more triagers and maintainers?

From where I sit it looks like one big barrier is communication. It's unreasonable to expect to get help you are not asking for. Why not create and document a place to discuss direction and bring together people who are interested in the advancement of the project as a whole? I know there must be plenty of them!