# Rseng Community Metrics > Covers measuring community health with CHAOSS-style metrics: contributor growth and retention, bus factor, first-response and review latency, the casual-to-regular contributor conversion funnel, and organizational diversity - computed from forge data, interpreted against project stage, and turned into community actions rather than vanity dashboards. Use when the user asks how healthy their community is, wants contributor or responsiveness statistics, mentions CHAOSS or community metrics, prepares a sustainability report or grant renewal needing community evidence, or when community trends (rising latency, shrinking contributor base) should be checked rather than felt. - Skill: `fdiblen/rseng-community-metrics` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add fdiblen/rseng-community-metrics` - Raw SKILL.md: https://api.skillmd.com/api/skills/fdiblen/rseng-community-metrics/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Marketing & Growth - License: CC-BY-4.0 - Author: fdiblen (https://skillmd.com/u/fdiblen) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/fdiblen/rseng-community-metrics --- # Community health metrics A community's health can be measured, and the CHAOSS project has standardized how: metrics for growth, responsiveness, retention and risk that turn "the community feels quiet lately" into checkable numbers. The same discipline as rseng-software-metrics applies unchanged: metrics LOCATE community problems, humans judge them; trends beat snapshots; and every metric can be gamed, so keep them plural and tie them to actions. ## The metrics that matter, and their sources Nearly everything comes from data the forge already has - git history, issues, PRs, reviews - all computable by an agent: - Growth and activity: new contributors per period, active contributors (authored, reviewed, triaged or commented - count ALL contribution kinds, the rseng-citation-metadata lesson), contribution volume by type. - Responsiveness: time to first response on issues and PRs (the promise rseng-community-governance made checkable), review latency, time to merge or close. First-response time is the single best predictor of whether a first-time contributor returns. - Retention and the funnel: how many first-time contributors make a second contribution (the conversion rate), casual-to-regular progression, time since last activity for previously regular contributors (quiet departures are findable before they are final). - Risk: bus factor (what fraction of recent work concentrates in how few people - the elephant-factor framing), single-maintainer subsystems, organizational concentration when affiliation is known. Compute from `git log`, the forge API and the tracker; CHAOSS tooling (Augur/GrimoireLab-class) automates it at scale, but a scripted quarterly pass covers most research projects (a natural milestone-review input - rseng-code-review). ## Interpreting honestly - Stage calibrates everything (rseng-quality-framework's tiering instinct): a two-person analysis-code repo with bus factor 1 is normal; infrastructure with bus factor 1 is a risk register entry. Compare the project against its own history first, peers second, absolutes never. - Watch trends, alert on inflections: slowly rising first-response time is load or fading attention - both actionable; a cliff after a maintainer change is a succession problem (rseng-community-governance). - Name the denominator: "12 new contributors" means nothing without the period and the definition; publish definitions with numbers so the metric survives scrutiny (rseng-research-integrity's spirit applied to community claims). - Diversity and affiliation metrics involve personal data: use public information, aggregate, and route anything finer to policy (rseng-regulatory-compliance). ## From numbers to actions Every reported metric ends with a routing, or it is a vanity dashboard: - Slow first response -> triage rotation and a stated timeframe (rseng-community-governance, rseng-project-tracking). - Poor first-to-second contributor conversion -> onboarding fixes (rseng-contributor-onboarding owns the funnel). - Support load rising in issues -> FAQ and docs routing (rseng-user-support, rseng-documentation). - Bus factor concentration -> knowledge spreading: rotation, documentation, succession planning (rseng-maintenance-sustainability). - Good numbers -> tell the community; measured health is a celebration and a grant-report asset (rseng-science-communication, rseng-management-planning). Report metrics to the community transparently on a cadence - a short health section in the periodic digest (rseng-project-tracking's high-level log) normalizes measurement and builds trust; surprise metrics deployed in conflict destroy it. ## Working with this skill This skill is source-independent: its authority is the CHAOSS metrics definitions and community-health practice linked below. It is the measurement arm of rseng-community-governance, the community analogue of rseng-software-metrics. Learn more (verified): - https://chaoss.community - CHAOSS community health metrics - https://www.cscce.org - Center for Scientific Collaboration and Community Engagement - https://opensource.guide - open source guides (community sections) ## Related skills Check whether any of these applies before moving on: - rseng-community-governance - metrics route to governance actions - rseng-contributor-onboarding - fixes the funnel leaks found - rseng-maintenance-sustainability - bus-factor risk response - rseng-management-planning - grant reports need community evidence - rseng-software-metrics - same measurement discipline, code side - rseng-user-support - support load is a signal