rseng-community-metrics

Solid

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.

Code & Development 14 stars 2 forks Updated 4 days ago MIT

Install

View on GitHub

Quality Score: 83/100

Stars 20%
39
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# 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 ...

Details

Author
fdiblen
Repository
fdiblen/rseng-agent-skills
Created
4 days ago
Last Updated
4 days ago
Language
Python
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Solid

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.

14 Updated 4 days ago
fdiblen
AI & Automation Listed

engineering-metrics

Use when measuring engineering team performance, setting up DORA metrics, using the SPACE framework, analyzing deployment frequency, lead time, change failure rate, MTTR, or presenting engineering productivity to leadership. Triggers on engineering metrics, team performance, productivity measurement, DORA, SPACE, OKRs for engineering, cycle time analysis, or any question about how to measure software teams without causing harm.

1 Updated 1 weeks ago
adammatthewsteinberger
AI & Automation Listed

principles

Metric literacy for what this plugin reports: what cyclomatic complexity, cognitive complexity, Halstead difficulty, lines per file, duplication, coverage, CRAP, and type debt mean, and what none of them can tell you. Four reference files carry the definitions and what each collector computes, each bundled reference value with its provenance (why cyclomatic 20, why 22 and 80 have no citation), the CRAP formula with its name history and coverage join, and an annotated bibliography (McCabe, Halstead, NIST SP 500-235, Campbell, Lewis 2013, ISO/IEC 5055 and 25023). Cross-metric caveats live here once; owners of the measures it leaves alone are named behind a presence gate. Use when: 'what does cyclomatic complexity mean', 'is CRAP a real metric', 'why is the cyclomatic reference 20', 'what is a good coverage number', 'which metric should I look at', 'code metrics principles'; for the numbers themselves run the /code-metrics:audit-* skills.

16 Updated today
melodic-software