writing-github-docslisted

# The repository's public face Three documents answering three different questions. Mixing them is the expensive mistake in this category, because the result reads complete. | File | Answers | Reader | Failure mode | |---|---|---|---| | `README.md` | What is this, and how do I run it | Someone passing through | Becomes a shrunken architecture document | | `CONTRIBUTING.md` | How do I take part, and what do you want | Someone about to change it | **Becomes a second quick start** | | Community health | Conduct, disclosure, licence, templates | The platform, and outside arrivals | Missing — and GitHub publishes the gap for you | **Writing CONTRIBUTING as a second quick start is the standard failure.** It reads fine: install the dependencies, run it, here is the directory layout. And every single thing that actually stops a contributor is absent — who reviews their pull request, how long before anyone replies, what kind of change will simply not be accepted, where to send a vulnerability. Unable to answer those, they guess, or they leave. ## These files need conventions of their own `docs/` conventions are designed for someone already inside: a scope header answers "does this document cover my situation", a routing table answers "which one do I read", immutability answers "is this still current". The public face has none of those problems. Its reader has a repository URL and thirty seconds. Adding a "does not cover" section to a README applies internal governance to a proble