Automated Project Health reports

[ebullient]

I am playing with how to automate gathering data to support a project health dashboard.

Here are some ideas:

• Data can be augmented with information in the private project repository
• Raw statistics collected in the private project repository (JSON)
• Rendered dashboards with aggregated data + signatory comments could be rendered as markdown + mermaid in GitHub and optionally on the website (foundation repository)

I would like some other opinions on information that is useful (or not) to include.

• Some information requires tending (like # of committers).
• Some information does not currently have a great API to fetch (download statistics from Maven, though there may be better ways to do this with upgraded tools).

Any other thoughts/ideas?

[aalmiray]

Repology lists versions available from a given set of package managers, for example https://repology.org/project/jreleaser/badges

Only applies for a subset of our member projects as not everyone produces binaries that fit into this category.

One could look at the impls from shields.io to find out how they calculate stats for other things that may be applicable to member projects. Or link directly to their badges.

[ebullient]

ok. I have a first pass.

https://github.com/commonhaus-test/project-test/tree/main/reports/2025-08-15

[ShaneCurcuru]

Thinking about how other orgs do this, it really depends both on what's important to your projects, and how easy it is to build (i.e. if projects use org service providers, or are spread around). Some ideas to consider (apologies if this is stuff you're already doing):

• Leverage default .github community health files - I've always thought it would be easy to agree on simple metadata to add in one of those files you could then use in a structured way, like name: value fields or even a consistent # header to parse.
• Look at the CHAOSS metrics for ideas of what's important to measure; I find it useful to see how they name statistics or describe them, to then translate to communities I'm interested in.
• Tease out which metrics individual projects will want for their own uses, vs. what metrics you want to track for your org as a whole and why.