Automation & CI
Automating Contributor Readiness Checks with GitHub Actions and WelcomeScore
Automating contributor readiness checks in CI ensures that documentation, starter issues, and license signals remain healthy across pull requests and releases.
Why verify contributor onboarding in CI?
Repository health degrades incrementally: a merge removes an essential setup step from the README, an issue template is inadvertently deleted, or a license notice is omitted from a new sub-package. Running checks in CI catches regressions before they affect new contributors.
The WelcomeScore GitHub Action runs deterministically without network dependencies, verifying public signals, generating structured reports, and optionally evaluating a minimum score threshold.
- Pin action versions (e.g. ethiorhq/welcomescore-action@v1).
- Set permissions to least-privilege (contents: read, pull-requests: write only if commenting).
- Upload report artifacts (.welcomescore/report.json and report.md) for CI run inspection.
Example GitHub Actions workflow configuration
Here is a complete, production-ready workflow for auditing contributor readiness on pull requests and pushes:
Save this workflow file in your repository at .github/workflows/welcomescore.yml. It runs on every pull request, asserts a score threshold of 80, and uploads the verified audit artifacts.
Connecting CI findings to the Next Useful Move
When an audit reports a gap—such as a missing CONTRIBUTING.md or unmaintained starter issue—the report output identifies the single highest-leverage next move.
Maintainers can review the generated issue draft or patch plan preview directly from the CI artifact or web dashboard at https://welcomescore.vercel.app/report/owner/repo.
About this guide
Written by ETHIOR Editorial for contributors and maintainers. This guide explains practical product and repository practices; it is not legal, security, employment, or financial advice. Review the project’s How It Works, Privacy Policy, and Terms & Conditions for product boundaries.
Put the ideas into practice
Run a fresh public GitHub audit and use the visible contributor signals as a starting point—not as a certification of project quality or safety.
Check a repository