WelcomeScore guide
How to use a WelcomeScore result to improve a repository
A WelcomeScore result is a practical starting point for improving public contributor signals. It is most useful when maintainers respond with real documentation and maintained starter work, not cosmetic score chasing.
Read the checklist before the grade
The individual checks explain more than the letter grade. A missing contribution guide means a newcomer may not know how to propose work. A missing setup section means they may not reach a local baseline. Missing starter issues means they may not find a safe place to begin. Treat each gap as a question about the contributor experience, not a directive to add an empty file.
The audit is intentionally narrow. It does not measure code quality, security, maintainer responsiveness, legal compliance, employment opportunities, funding, community health, or whether a pull request will be accepted. Use it with your own judgment and the project’s real needs.
Improve signals in the order a newcomer experiences them
Start with a usable README setup section and CONTRIBUTING.md, then explain conduct and licensing, then create a small set of real newcomer tasks. This order gives someone enough context to understand and complete the work you label as approachable.
Avoid score-only fixes. A placeholder code of conduct, copied license you do not understand, or vague issue labeled good first issue may change an output, but it will not make the repository more welcoming. Accurate files and maintained issues create the durable benefit.
- Verify setup from a clean local environment.
- Write contribution expectations that match actual maintainer practice.
- Use a license and attribution notices that you understand and have reviewed as needed.
- Label only real, bounded starter tasks.
Request a fresh audit after meaningful changes
WelcomeScore treats a deliberate Check or Compare action as a fresh public GitHub audit. If you have just merged documentation or opened a starter issue, run the audit again after GitHub has made those public changes available. Shareable badges have their own short cache to remain reliable in repository READMEs.
A refreshed result may still differ from your expectation if GitHub has not indexed a new issue, the file name differs from the documented signal, the setup heading is unclear, or a repository is temporarily rate-limited. Check the individual result pills and resolve the real source rather than repeatedly refreshing.
Use public recognition carefully
Hall of Fame eligibility is a product rule based on a fresh score plus real public repository signals. It is not an endorsement or certification. A high score should be an invitation to keep the onboarding path honest, current, and useful.
If you choose an optional Algofox review, treat it as concise evidence-bound guidance. It is not a legal, security, hiring, financial, or quality assessment of the project or its maintainers.
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