# Community health

> How inspect.software measures community health — README, license, contributing guide, code of conduct, and issue/PR templates. 6.3% of the overall index.


**Community health** measures whether a repository is set up to receive users
and contributors: the standard files that tell a newcomer what the project
is, on what terms it may be used, and how to participate. These files are the
difference between a codebase and a community.

- **Category:** [Community & Adoption](/wiki/community-adoption) (35% within category)
- **Weight in overall index:** 6.3%
- **Metric key:** `community_health`

## How the value is computed

A weighted checklist of the standard files, each present or absent (the
license row can also earn partial credit — see below):

| Component | Weight |
| --------- | ------ |
| README | 22.5 |
| License | 22.5 |
| CONTRIBUTING guide | 18 |
| Code of conduct | 13.5 |
| Issue template | 7.2 |
| PR template | 6.3 |

## How the license is detected

License presence is checked once, from three sources considered together: the
repository's own license metadata, GitHub's community profile, and
[OpenSSF Scorecard](https://github.com/ossf/scorecard)'s published,
tool-neutral `License` check. A file that **any** source sees counts as
present — the sources disagree on roughly 1% of repositories, and a single
unavailable endpoint must not report a license as missing.

The result is one of three states:

| State | Meaning | Credit |
| ----- | ------- | ------ |
| Standard | A recognized license, identified by SPDX code | 22.5 |
| Custom | A license file is present, but its text is not a recognized license | 16.9 |
| None | No source found a license file | 0 |

A **custom license** is a real license and earns most of the weight. It does
not earn all of it: a license automated tooling cannot identify is a genuine
obstacle to adoption, because policy tooling, corporate review and package
registries all key off recognized identifiers, and a reader cannot establish
what they are permitted to do without reading the text themselves. GitHub
reports this case as `NOASSERTION` — a license it found but could not
classify, which is not the same as no license at all.

The Scorecard result remains a component of the
[security](/wiki/security-posture) metric; here it is one input among three,
shown simply as `License`.

## Why these files carry weight

- **README and license are load-bearing.** A repository without a README is
  unadoptable; a repository without a license is legally unusable in most
  organizations — no downstream legal team will approve a dependency whose
  terms are undefined. Together they carry half the metric.
- **CONTRIBUTING and a code of conduct** convert drive-by interest into
  sustained participation, which feeds directly into the continuity measured
  by [maintainer resilience](/wiki/maintainer-resilience).
- **Templates** raise the signal quality of incoming issues and pull
  requests, reducing maintainer triage load — a small but real factor in the
  [responsiveness](/wiki/responsiveness) a project can sustain.

## Reading the result

- The checklist is scale-independent: a week-old project can reach 100 before
  its first star, and a famous project missing a license reads visibly
  incomplete. That is intended — this metric measures preparation, not
  traction.
- Presence is what is verified, not prose quality — see the measurement
  honesty note in [signals, not warranties](/wiki/signals-not-warranties).

## Improving the value

Every component is directly actionable within an hour:

- Write a README covering what the project does, installation, and a minimal
  example.
- Add a `LICENSE` file with a recognized SPDX license.
- Add `CONTRIBUTING.md`, a `CODE_OF_CONDUCT.md`, and issue/PR templates under
  `.github/`.

This is typically the fastest metric to move in the entire methodology.

Related: [Community & Adoption](/wiki/community-adoption) ·
[documentation](/wiki/documentation)