# Rseng Community Governance > Covers building and governing a community around research software: CONTRIBUTING guides, codes of conduct, governance models and decision-making, contributor recognition policy, issue and discussion hygiene, and handing over or sharing maintainership. Use when a project wants external contributors, when the user asks for a CONTRIBUTING.md, code of conduct or governance document, when maintainer burnout or bus-factor risks come up, or when a project is moving from single-author to team or community ownership. The contributor funnel and good-first-issue curation live in rseng-contributor-onboarding; health measurement in rseng-community-metrics; support operations in rseng-user-support. - Skill: `fdiblen/rseng-community-governance` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add fdiblen/rseng-community-governance` - Raw SKILL.md: https://api.skillmd.com/api/skills/fdiblen/rseng-community-governance/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Research & Search - License: CC-BY-4.0 - Author: fdiblen (https://skillmd.com/u/fdiblen) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/fdiblen/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