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):
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
1---2name: rseng-community-metrics3description: 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.4license: CC-BY-4.05---67# Community health metrics89A community's health can be measured, and the CHAOSS project has10standardized how: metrics for growth, responsiveness, retention11and risk that turn "the community feels quiet lately" into12checkable numbers. The same discipline as rseng-software-metrics13applies unchanged: metrics LOCATE community problems, humans judge14them; trends beat snapshots; and every metric can be gamed, so15keep them plural and tie them to actions.1617## The metrics that matter, and their sources1819Nearly everything comes from data the forge already has - git20history, issues, PRs, reviews - all computable by an agent:2122- Growth and activity: new contributors per period, active23 contributors (authored, reviewed, triaged or commented - count24 ALL contribution kinds, the rseng-citation-metadata lesson),25 contribution volume by type.26- Responsiveness: time to first response on issues and PRs27 (the promise rseng-community-governance made checkable), review28 latency, time to merge or close. First-response time is the29 single best predictor of whether a first-time contributor30 returns.31- Retention and the funnel: how many first-time contributors make32 a second contribution (the conversion rate), casual-to-regular33 progression, time since last activity for previously regular34 contributors (quiet departures are findable before they are35 final).36- Risk: bus factor (what fraction of recent work concentrates in37 how few people - the elephant-factor framing), single-maintainer38 subsystems, organizational concentration when affiliation is39 known.4041Compute from `git log`, the forge API and the tracker; CHAOSS42tooling (Augur/GrimoireLab-class) automates it at scale, but a43scripted quarterly pass covers most research projects (a natural44milestone-review input - rseng-code-review).4546## Interpreting honestly4748- Stage calibrates everything (rseng-quality-framework's tiering49 instinct): a two-person analysis-code repo with bus factor 1 is50 normal; infrastructure with bus factor 1 is a risk register51 entry. Compare the project against its own history first,52 peers second, absolutes never.53- Watch trends, alert on inflections: slowly rising first-response54 time is load or fading attention - both actionable; a cliff55 after a maintainer change is a succession problem56 (rseng-community-governance).57- Name the denominator: "12 new contributors" means nothing58 without the period and the definition; publish definitions with59 numbers so the metric survives scrutiny60 (rseng-research-integrity's spirit applied to community claims).61- Diversity and affiliation metrics involve personal data: use62 public information, aggregate, and route anything finer to63 policy (rseng-regulatory-compliance).6465## From numbers to actions6667Every reported metric ends with a routing, or it is a vanity68dashboard:6970- Slow first response -> triage rotation and a stated timeframe71 (rseng-community-governance, rseng-project-tracking).72- Poor first-to-second contributor conversion -> onboarding fixes73 (rseng-contributor-onboarding owns the funnel).74- Support load rising in issues -> FAQ and docs routing75 (rseng-user-support, rseng-documentation).76- Bus factor concentration -> knowledge spreading: rotation,77 documentation, succession planning78 (rseng-maintenance-sustainability).79- Good numbers -> tell the community; measured health is a80 celebration and a grant-report asset81 (rseng-science-communication, rseng-management-planning).8283Report metrics to the community transparently on a cadence - a84short health section in the periodic digest85(rseng-project-tracking's high-level log) normalizes measurement86and builds trust; surprise metrics deployed in conflict destroy87it.8889## Working with this skill9091This skill is source-independent: its authority is the CHAOSS92metrics definitions and community-health practice linked below.93It is the measurement arm of rseng-community-governance, the94community analogue of rseng-software-metrics.9596Learn more (verified):97 - https://chaoss.community - CHAOSS community health metrics98 - https://www.cscce.org - Center for Scientific Collaboration99 and Community Engagement100 - https://opensource.guide - open source guides (community101 sections)102103<!-- related-skills:begin -->104105## Related skills106107Check whether any of these applies before moving on:108109- rseng-community-governance - metrics route to governance actions110- rseng-contributor-onboarding - fixes the funnel leaks found111- rseng-maintenance-sustainability - bus-factor risk response112- rseng-management-planning - grant reports need community evidence113- rseng-software-metrics - same measurement discipline, code side114- rseng-user-support - support load is a signal115116<!-- related-skills:end -->