Running it after release.
WHAT MAINTENANCE INVOLVES
Responding to issues Reviewing contributions Releasing versions Handling security reports Answering questions Making decisions about direction
WHY IT IS UNDERESTIMATED
The work continues indefinitely and it grows with adoption.
WHAT TO ESTABLISH
Who does it, with time allocated.
WHAT TO PUBLISH
What the project is and is not What is supported How to report issues How to contribute How decisions are made The release approach
WHY STATING WHAT IT IS NOT
It prevents requests and expectations you will not meet.
WHAT TO ESTABLISH ABOUT RESPONSE
What users can expect.
WHY
Unstated expectations are always higher than reality.
WHAT TO DO ABOUT ISSUES
Acknowledge them, even where you will not act.
WHY
Silence drives users away and it discourages contribution.
WHAT TO ESTABLISH ABOUT CONTRIBUTIONS
Guidelines stating what is acceptable Review before merging A response, including refusals with reasons
WHY REASONS
Contributors whose work is rejected without explanation do not return.
WHAT TO ESTABLISH ABOUT SECURITY REPORTS
A private route for reporting A commitment to respond A disclosure approach
WHY PRIVATE
Public reporting of a vulnerability exposes users before a fix exists.
WHAT TO PUBLISH
A security contact.
WHAT TO ESTABLISH ABOUT RELEASES
Predictable versioning Clear notes on what changed Marking of breaking changes
WHAT TO PLAN FOR
Your own capacity changing.
WHAT TO DO IF YOU CANNOT MAINTAIN IT
Say so, clearly, and seek a maintainer.
WHY
Silent abandonment leaves users exposed.
