You also need to close issues after a set amount of inactivity[2].
If there is a bug without a CVE, or a feature someone wants fixed that users don't want to submit a fix for themselves AFTER it has been discussed with the maintainer in an issue with a replication or strawman proposal and the owner has created a draft pr and asked you to work on it, it probably needs to come with a Patreon donation[3]. This can help alleviate maintainer burnout by allowing the maintainer to hire someone to make the contribution.
A software shop wouldn't operate without some kind of iterative plan. Large open source projects with single maintainers shouldn't either. Scheduling 1 or 2 hours a week for issue triage, hosted in an online meeting, and limiting WIP in terms of open PRs to be discussed during this triage meeting should allow for both community interaction and strong governance for the project and prevent burnout for the maintainer.
All of this can be placed into the Readme or Contributor guide and a CLA that contributors have to sign.
Otherwise, people can fork and maintain the project themselves.
If you want to prevent flame wars, or demotivating comments, something like a comment sentiment analysis app[4] might even be a good idea to add to your project. There are plenty of models available that you can delegate to for this in the wild, and it's worth automating moderation to prevent burnout.
Finally, really toxic users can and should be banned[5]. It's not worth it to deal with anonymous negative contributors all the time.
1. https://github.com/marketplace/actions/close-pull-request
2. https://github.com/marketplace/actions/issue-triage
3. https://github.blog/changelog/2023-10-03-sponsor-projects-th...
4. https://github.com/marketplace/comment-sentiment-analyzer
5. https://docs.github.com/en/communities/maintaining-your-safe...