Community
18% of overallDoes anyone outside the company show up — and are they having a good time?
What it measures
We combine GitHub community signals (PRs from outside the org, external contributors, GitHub Discussions activity, fork engagement, issue triage) with LLM-graded issue sentiment, Discord presence, and verified community programs (Ambassadors, MVPs, Champions, etc.).
Why it matters
A healthy community is the strongest long-term moat in developer tooling. External PRs and Discussions are leading indicators of adoption; sentiment is a fast read on whether the relationship is healthy or fraying.
Sub-metrics
| Metric | What we read | Weight | Source |
|---|---|---|---|
| GitHub community score | External PRs, contributors, discussions, fork engagement, issue triage | 55% | GitHub REST + GraphQL |
| Issue sentiment | (positive − negative) / sample size, rescaled to 0–100 | 15% (when sample exists) | LLM sample over recent issues |
| Discord presence | Public Discord/Slack invite linked from site or docs | 10% | Org links + docs crawl |
| Verified community programs | Ambassador / MVP / Champion / Heroes pages (capped at 3) | 20% | Site crawl + verification |
How it's weighted
GitHub activity from people outside the org carries the most weight, followed by verified community programs. Discord presence and issue sentiment fill in the picture but don't dominate it.
Best practices
- Turn on GitHub Discussions and seed it with a few real Q&A threads.
- Run a public Discord (or Slack) with a code of conduct, channels per topic, and at least one staffed channel.
- Define and name a community program — Ambassadors, Champions, MVPs — with a public application page.
- Commit to a first-response SLA on issues. Even 'we saw it, looking next week' beats silence.
- Publish a roadmap or RFC repo so the community knows where things are going.
- Reply to PRs even when you can't merge them — the response speed shapes future contributions.