Rseng Community Governance

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

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

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: fdiblen
• Source: fdiblen/rseng-agent-skills
• License: MIT

Install and usage instructions live in the source repository linked above.