The moment your side project gets its first real user, it stops being your side project. It’s now a piece of infrastructure someone else depends on, and the bill for that arrives as issues, support DMs, and a Slack full of “any update on this?” Most maintainer burnout isn’t caused by the code. It’s caused by never deciding the boundaries before the project needed them.

Triage before you read every issue

An unread issue queue feels like an obligation. Treat it like a queue with a process instead of a guilt list:

flowchart TD
    A["New issue"] --> B{"Minimal repro?"}
    B -->|No| C["Label needs-repro, auto-comment template"]
    C --> D["Close after 2 weeks of silence"]
    B -->|Yes| E{"Bug or support question?"}
    E -->|Support| F["Point to docs/Discourse, close"]
    E -->|Bug| G["Label by severity, leave open"]
  

Automate the first branch with a GitHub Action or a bot (something like actions/stale for the close-after-silence part). Most maintainer time goes to issues that were never going to get fixed anyway because nobody, including the reporter, put in the minimum info to act on them. A template and a bot handle that layer so you only spend real attention on the issues that need it.

Set support boundaries in writing, in the repo

If you don’t say where support happens, it happens everywhere — GitHub issues, your personal email, your DMs, at 11pm. Put a SUPPORT.md or a section in the README:

## Getting help
- Bug reports: GitHub Issues (use the template)
- Questions: GitHub Discussions
- Not supported: DMs, email, Discord pings for support requests

You will still get DMs. The difference is you now have somewhere to point people, and a boundary you set on purpose instead of one you’re enforcing out of exhaustion six months in.

Decide your response-time policy honestly

Don’t imply 24/7 maintenance for a project you work on in evenings. A line in the README sets expectations before anyone’s disappointed:

This is maintained in my spare time. I aim to respond to issues
within a week, not immediately. PRs with tests move faster than
issues without them.

That last sentence does real work — it nudges people toward contributing a fix instead of just reporting a problem and waiting.

The maintainer’s real lever: good-first-issue labeling

The fastest way to reduce your own load is to convert users into occasional contributors. Tag small, well-scoped issues explicitly:

good-first-issue: fix typo in error message for invalid config
good-first-issue: add missing return type to `parseOptions()`

Vague “good first issue” labels on genuinely hard problems train contributors not to trust the label, and you lose the tool entirely. Reserve it for things that are actually small.

Know when to say the project is in maintenance mode

There’s no shame in this, and it’s better than silent abandonment that leaves users guessing whether a security issue will ever get patched. State it plainly:

## Project status
This project is in maintenance mode. I'll merge bug fixes and
security patches, but I'm not adding new features. Forks welcome.

This one sentence prevents more frustration than any amount of individual issue triage — it tells people exactly what to expect before they invest time filing a feature request that was never going anywhere.

The boundary that saves you

Decide, before you’re burned out, which parts of the project are worth your unpaid time and which aren’t. Security patches and data-loss bugs: yes, always. Feature requests from people who’ve never opened a PR: maybe, on your schedule, not theirs. The maintainers who last years are the ones who set that line early — not the ones with the least popular projects.

---