rseng-community-governancelisted

# Community and governance for research software Most research software dies with its author's contract. A community - even a small one - is the strongest sustainability mechanism a project has (rseng-maintenance-sustainability covers the technical side; this skill covers the human side). Governance is not bureaucracy: it is writing down who decides what, so contributors can act without waiting and maintainers can step back without collapse. ## The contribution surface Make contributing possible before promoting it: - CONTRIBUTING.md: how to set up a dev environment (rseng-reproducible-environments), run tests (rseng-testing), propose changes (rseng-version-control-review), and what kinds of contribution are welcome (docs, examples and issue triage count). - Code of conduct: adopt the Contributor Covenant rather than writing one; name real enforcement contacts - an unenforceable CoC is worse than none. - Issue templates and labels: a good-first-issue label with genuinely scoped starter tasks is the single best onboarding tool. - Respond to first-time contributors fast and kindly; the first interaction decides whether there is a second. - Name the communication channels: where questions go (discussions, a chat channel, a mailing list), stated in the README and CONTRIBUTING - an active, discoverable channel is itself a measured community-health indicator; one well-tended channel beats three dead ones. - Define a response timeframe and say it out loud (