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!

[StringEpsilon]

Another thing would maybe to temporarily decline new feature requests so that new work isn't piled on top. Have a bit of maintenance only phase where the focus is on getting the already planned work (for the release) done and fixing known bugs.

If help with triage is welcome, I'm happy to go over the backlog and note down tickets I think can be closed and why. Just tell me how I can go about that in a useful way.

Edit: I took a couple minutes to just collect some. See this gist: https://gist.github.com/StringEpsilon/bd7c87f6addd26328148c5e95b0e5c37 - will update that as I find time to scroll through the backlog.

[SimenB]

@conartist6 sure, I'd love to make that happen. Any concrete suggestions?

(getting triaging permission is more about getting fb/meta to do anything - I don't have the accesses necessary, and neither do most employees.)

@StringEpsilon thank you so much, that's awesome! I'll go through tomorrow or monday. That's exactly the sort of help I'd love to have 🙂

[conartist6]

@SimenB I see only three options: facebook puts forward new owner/maintainers, the project is forked, or the project dies.

It seems to me that you had the opportunity to become a core maintainer due to the fact that @cpojer was an active owner of the project at the time you started contributing around 2018 (see graphs). I'm assuming that since active owners were reviewing your contributions, you gained their trust and eventually received privs. Unfortunately since that pathway to gaining new owners and maintainers no longer exists, it seems like you are the only thing keeping the project from being abandoned.

I know this is a bit of a provocative thing to say, but I think that you should fork the project.

[cpojer]

I cannot perceive a fork to be a good outcome for Meta, Jest contributors or the community. We are talking to Meta about actions we could take, but there is nothing new to report at this time.

tbh, the way you are coming across sounds like you have a chip on your shoulder regarding Facebook more than focusing on the best outcomes for everyone.

[conartist6]

I understand that perspective completely. And I do have a bit of a chip on my should as regards facebook, but I do not think it is relevant here.

I've also spent the last two years working on tools that would make decentralized package development a reality in the npm ecosystem, something which I see the value in doing only because so many prominent open source projects have such substantial problems with trust which lead to large amounts of immensely valuable work falling on the shoulders of a few individuals.

Ultimately I see users being able to set up their package.json like this:

{
  "devDependencies": {
    "jest": "github:trustedmaintainer/jest"
  }
}

A package decentralized in this manner will be far less susceptible to permanent abandonment, and it puts front and center the real question: who do you trust? Yes, facebook's name is on jest, but anyone currently using it is essentially agreeing to trust @SimenB. If I had the option to install github:simenb/jest I would indeed be immediately prompted to ask whether I trust simenb, and after I saw that he's written most of the lines of the code in the project, the answer would be yes.

[cpojer]

Thanks for drafting up your proposal. I do not think this issue – nor the Jest issue tracker in general – is the right place to discuss your projects and vision for the JavaScript package management ecosystem. Let's re-center this discussion on Jest so the stakeholders of the project can work with Meta to identify a path forward. I wish you all the best on your project.

[conartist6]

I am only describing what is possible. I am sorry, but I do not think that doing so is either irrelevant or inappropriate.

[vjeux]

(getting triaging permission is more about getting fb/meta to do anything - I don't have the accesses necessary, and neither do most employees.)

Let me look into it on Monday. It should be possible, we’ve done it for other repos.

[conartist6]

@vjeux Thank you for doing that.

I know I am stirring the pot here, but I really have only gratitude for the people who have invested their time and energy in this project, and I'd be more than happy to see meta step forwards and provide better support.

That said, I'd love to see the process of engaging with the project's owners/governance (to confirm, that is the Meta OSS organization?) play out publicly! Meta benefits greatly from the investment the community has made in this project, so I would hope that they could be something other than a complete black box to the non-meta-employee community.

[conartist6]

I have sent the following message to [email protected], subject line: Jest

To whom it may concern,

I am writing to formally request that you publicly name an administrative owner and/or a community point of contact for the jest open source project. I am aware that I am in essence asking you to spend money on this project, and that it is likely one which is no longer of strategic importance to Meta. The project is of strategic importance to the community though, and the community is chomping at the bit to help develop and maintain it. Its chief competitors are nowhere close to its functionality or ease of use.

I am aware that your organization is primarily set up to export open source software, but in this case you are already in the position of relying heavily on a project which the community maintains for you. The community provides you great value in its [work], but its efforts are also greatly hampered by the complete silence of the project's owners. I implore you to invest even a little in governance of this project to guide the community towards unlocking the potential it has. I have "carbon-copied" this message to a thread on the jest issue tracker, and would appreciate a response there.

Regards,
Conrad

Edit: missing [work]

[rickhanlonii]

I am writing to formally request that you publicly name an administrative owner and/or a community point of contact for the jest open source project.

@conartist6 this exists, it is me. Thanks for pushing this, the core maintainers are fully able to handle it. I'm going to lock this as too heated, but thanks again for your perspective.

[vjeux]

I just wanted to give an update. As a follow-up of this thread, we've concretized the plan to move Jest to a foundation which just materialized today. Hopefully this new structure will help with the challenges mentioned here. https://engineering.fb.com/2022/05/11/open-source/jest-openjs-foundation/