Write down what you will and will not do in your README: review schedules, pull request requirements, support limits and response times you can actually keep. Open Source Guides recommends this as a way to set boundaries and decline requests you cannot meet, which helps prevent burnout.
Why write it down
A maintainer who answers every request fast teaches users to expect it. When capacity drops, silence reads as neglect. A short statement of limits makes the default clear, and it gives you something to point to when you decline a request.
The guide lists difficulty saying no as a common cause of imbalance, and suggests documenting what you will and will not do in the README, such as review schedules or PR requirements.
A section you can copy
Create a short heading such as "How this project is maintained". Cover these points in plain sentences:
- Availability. When you review pull requests, for example "weekends are off" or "reviews happen when time allows".
- Scope. What the project is for, and what it is not. Requests outside scope may be closed.
- Pull request rules. Tests required, size limits, one change per request, how to sign off.
- Support. Where questions go, and that the issue tracker is for bugs.
- Security reports. Where to send them privately. See turning on private vulnerability reporting.
- Backup contact. A second person who can respond when you are away.
Tone
Be firm and kind. A boundary is not a complaint. "I cannot review large changes without a prior discussion" is easier to hear than a long apology. The guide also advises being firm with abusive or negative interactions and not spending energy on things you do not care about.
Share the load
The same guide recommends delegating, recruiting contributors, and keeping more than one point of contact so that breaks are possible. A boundaries section works better when a second maintainer can enforce it. Name them and give them rights to triage.
Use your status
Setting your GitHub status to show availability tells people in a glance whether to expect a reply. It costs nothing. The guide lists it among its suggestions for resting deliberately.
What users should do with it
If you consume a project, read this section before you depend on it. It tells you what support to expect. A project that says "best effort, no response guarantee" is fine for a hobby tool and risky for a payment path. Plan accordingly: see the signs of burnout and how to help maintainers without money.
Review it twice a year
Capacity changes. A section written in a busy period may be too optimistic or too grim six months later. Put a reminder in your calendar and update the page.
Safeguard's SBOM and dependency scanning help teams see which projects they rely on, and you can try a free scan.
Quick check
Should I promise response times?
Only ones you can keep. A missed promise is worse than none.
Where should the boundaries live?
In the README, where every new user and contributor will see them.
Sources
Last reviewed: 19 October 2026.
