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 ("issues get a first response within a week"): a stated expectation both reassures contributors and is checkable - response-within-a- defined-timeframe is how community health gets assessed from the outside. Pick a promise the maintainers can keep.

Governance, sized to the project

Write down the smallest true answer to "who decides":

• Single maintainer: say so ("BDFL-style; decisions by @name") - honesty beats pretense of process.
• Small team: document maintainer roles, how consensus is reached, and what happens on disagreement.
• Community-scale: consider a lightweight governance doc covering roles, decision process, and how new maintainers are added - opensource.guide's leadership-and-governance section catalogs proven patterns.

Contribution and recognition policy: state how contributors are credited - AUTHORS/CONTRIBUTORS file, changelog mentions, and citation metadata for substantial contributions (rseng-citation-metadata). Credit is the currency research contributors are paid in; be generous and systematic.

Onboarding and the bus factor

• Capture maintainer knowledge in docs as it is used: release runbooks (rseng-publishing-releasing), triage guidelines, architecture notes (rseng-documentation). If only one person can do a task, that task needs a document.
• Rotate responsibilities when there are two or more maintainers; the second person on releases halves the bus-factor risk.
• Handover: when a maintainer leaves, announce it, transfer forge permissions and registry ownership explicitly, and record the change - abandoned-looking ownership blocks both contributors and security response (rseng-security).

The wider community toolkit

Measurement, support and onboarding each have their own skill: community health metrics (rseng-community-metrics), support operations and the answer-once pipeline (rseng-user-support), and the contributor funnel from first issue to regular (rseng-contributor-onboarding) - this skill owns the rules and structures they operate within.

Sustaining participation

• Roadmap visibly (even a pinned issue): contributors invest where direction is clear (rseng-management-planning).
• Thank and release often: shipped contributions retain contributors; ones stuck in review for months lose them.
• Watch for burnout signals in maintainers - unanswered issues and guilt-driven replies - and respond by narrowing scope honestly (declaring feature-freeze or maintenance-mode is legitimate governance).

Working with this skill

This skill is source-independent: its authority is the community guidance linked below.

Learn more (verified):

• https://opensource.guide - GitHub's open source guides (building community, leadership and governance)
• https://www.contributor-covenant.org - the Contributor Covenant
• https://www.software.ac.uk/guide/starting-community-taking-your-software-world - SSI guide on starting a community

<!-- related-skills:begin -->

Related skills

Check whether any of these applies before moving on:

• rseng-citation-metadata - systematic contributor credit
• rseng-community-metrics - measures the stated promises
• rseng-contributor-onboarding - funnel and first-issue curation
• rseng-maintenance-sustainability - technical side of sustainability
• rseng-security - ownership handover unblocks security response
• rseng-user-support - support channel operations

<!-- related-skills:end -->