danylomikula.ansible_hugo_deploy

What is costing points

Each of these is a signal we observed and could not fully credit.

• quality.changelog

  Ship a `changelogs/changelog.yaml` — the structured form `antsibull-changelog` generates and the `ansible` package consumes — rather than only a hand-maintained `CHANGELOG.md`, and write a fragment into `changelogs/fragments/` as each change lands rather than reconstructing release notes at release time. Both have to be inside the published tarball to be observable: a changelog that lives only in your Git repository is one we cannot read. This is the single highest-leverage change for most collections, because the same missing file is what holds down both changelog rules in this rubric. If you already publish `changelog.yaml` with fragments, this rule is answered.

• quality.docs

  Ship your README and your `docs/` directory INSIDE the published tarball, not only in your Git repository — we do not read repositories at all yet, so a file that exists only there is a file we cannot see. If your `build_ignore` excludes `docs/`, that exclusion is why we observed nothing. Beyond the README this rule counts documentation FILES, so splitting a long README into per-module and per-role pages is what moves it; adding filler pages to raise a count would satisfy the arithmetic and help nobody.

• quality.license_quality

  Declare a machine-readable SPDX identifier in `galaxy.yml`’s `license` field rather than relying on a `LICENSE` file alone: an identifier is what a consuming organisation’s policy tooling reads without a human opening the file. A `LICENSES/` directory following REUSE ranks above a bare root licence file and below the identifier. One exception worth stating: we record the identifier you publish rather than validating it against the SPDX list, so a wrong identifier will earn these marks and mislead your users at the same time — if no SPDX identifier fits your licence, publish the file instead.

• maintenance.release_recency

  Cut a release to Galaxy. This is the heaviest single rule in the rubric because a release is the one unambiguous, publisher-controlled act of maintenance we can observe without reading your repository — which is also its limitation, and worth saying plainly: a collection under active development that rarely releases is under-credited here, and that is a gap in what we can see rather than a judgement about the work. If your collection is finished rather than abandoned, there is nothing here you should change on our account.