Enabling a stale issue bot on my GitHub repositories

For the past few years, the number of issues and PRs across all my GitHub repositories has gone from a steady stream to an ongoing deluge. There are currently over 1,500 open issues across my 194 GitHub repositories, and there's no way I can keep up with all of them.

Initially, I went through each issue in each project's issue queue on a monthly basis (mind you, this was—and is still—done on nights and weekends in my spare time). That slipped to a quarterly task... and has now slipped to only happening for higher-profile projects once or twice a year .

To keep up with the constant barrage of new issues and PRs, many open source projects have employed a 'stale issue' bot ( Probot: stale ), which marks issues/PRs with no activity stale, then later closes them. Many issues are opened and never get a follow-up visit from the original author (even if I spend a half hour providing a thorough response). Often this person found a solution elsewhere and never thought to follow-up, or they don't have notifications enabled so they never even know someone responded.

Instead of letting these zombie issues clutter up the issue queue, the stale bot helps prune them.

You may have been directed to this issue from one of the issue closure notices.

Know that I don't close issues out of spite, or anger, or because I think the bug report, feature request, or other contribution has no value. Rather, unless something is breaking stability (e.g. a project I maintain won't install anymore, or breaks completely and CI blows up), or there's a major feature or missing component that I agree would be a no-brainer to have incorporated, I simply lack the bandwidth to be able to review the issue or PR.

One way you can help me get more bandwidth is to sponsor me on GitHub .

I can't promise sponsorship will lead me to reviewing your issue or PR more quickly, but one major problem with today's open source development model is the income generated from the tireless effort of open source maintenance is a pittance, and until that changes, I don't have the ability to devote more time to code review and responding to the deluge of open issues.

Aside : People have often mentioned I should cede control of my projects to others if the maintenance burden is to high, but they don't realize that (a) that would mean I don't have control over projects I built for myself and use in projects that contribute to my own income, and (b) giving control over a project in my namespace is something I don't take lightly at all , because I entrust all the project's users to the new maintainer. I don't take the responsibility of maintainership lightly, as trust is a valuable asset and is easy to lose.