Quality Bar

There's no star floor. A repo with 12 stars and a careful maintainer belongs here more than a 40,000-star repo nobody has touched since 2021. What the bot checks instead is whether the repo is real, open source, documented and alive.

Every check below runs when you submit. If one fails, the bot's comment quotes the message in the last column, so you can search this page for it.

The checks at a glance

#	Check	Passes when	The bot says, if it fails
1	Repo exists	GitHub can find it publicly	"We couldn't find that repo on GitHub. Is it public?"
2	Old enough	Created 30 or more days ago	"New repos need to be at least 30 days old..."
3	Recently pushed	A push in the last 90 days	"This repo hasn't had a push in the last 90 days."
4	Not archived	Not archived on GitHub	"This repo is archived. Unarchive it to be listed."
5	Not a bare fork	Not a fork, or a fork with its own commits	"Forks need their own commits to be listed."
6	Open-source license	An OSI-approved license is found	One of three license messages
7	Real README	A README with at least 300 characters of prose	"Add a README..." or "Your README needs a bit more detail..."
8	Repo description	The repo's About box has a description	"Add a short description to the repo..."
9	Not deprecated	The repo doesn't call itself deprecated or unmaintained	"This repo says it's "deprecated"..."
10	2 of 7 extras	Two or more community extras	"Add at least two of these to the repo: ..." or "Add one more of these..."

Your own description, the one you type into the form, has separate rules. They're on Submitting a Repo. Your account has to pass the Trust Checks too.

1. The repo exists and is public

Private repos, typos and deleted repos all fail here, because the bot looks the repo up through the GitHub API and finds nothing.

Fix: check the spelling of owner/name and make sure the repo is public. A renamed repo works under either name, since the bot follows GitHub's redirect.

2. At least 30 days old

A month filters out the weekend projects that are never touched again, and the repos made only to be listed. The clock starts on the day the repo was created on GitHub.

Fix: wait. Come back once the repo is a month old.

3. A push in the last 90 days

What matters is the repo's last push date, and a push to any branch counts.

Fix: push something. A finished, stable project is fine, but it needs a sign of life in the last three months to be listed.

4. Not archived

Archiving makes a repo read-only on GitHub, which tells people it's done.

Fix: if it's yours and still maintained, unarchive it under Settings > General > Danger Zone.

5. Forks need their own commits

A fork passes when its default branch is ahead of its parent's default branch, which means it has commits of its own. A fork that only mirrors its parent should be listed as the parent.

Fix: submit the original repo instead, or push the fork's own work to its default branch.

6. An open-source license

The license has to be on the OSI-approved list. Source-available licenses don't qualify, however open they feel.

Learning & Resources is the one exception. Its entries are mostly text, so it also takes CC0-1.0, CC-BY-4.0 and CC-BY-SA-4.0. Other categories don't.

The bot looks in this order and stops at the first answer:

1. GitHub's own detection. This is the license GitHub shows in the repo's sidebar. If GitHub names an OSI license, the check passes. If it names a license that isn't OSI-approved, the check fails. If it shows nothing, or just "Other", the bot keeps looking.
2. License files in the root folder, when GitHub found nothing. The bot reads up to 5 files named like LICENSE, LICENCE, COPYING or UNLICENSE, including versions such as LICENSE.md, LICENSE.txt or LICENSE-MIT. It accepts an SPDX-License-Identifier: line, or the standard text of a common license (MIT, Apache-2.0, the BSD and GPL families, MPL-2.0, ISC, the Unlicense and a few more). Symlinked license files aren't followed.
3. The README's License section, when there's no license file at all. The bot reads the first two lines under a heading called "License" or "Licence" and looks for a license name, such as "MIT" or "Apache 2.0".

In steps 2 and 3, a mention of a source-available license fails the check outright, even if another license file names an OSI license. That covers the Server Side Public License, the Business Source License, the Elastic License, the Redis Source Available License, the Commons Clause, PolyForm, the Functional Source License, Fair Source and the JSON License.

A standard license with a restriction tacked on, such as "MIT, but not for commercial use", fails too. The message names it as, say, "MIT with an added restriction".

The three license messages

Message	What it means	Fix
"We need an open-source license GitHub can recognise (like MIT or Apache-2.0)."	GitHub detected a license, and it isn't OSI-approved.	Switch to an OSI-approved license, if it's your repo.
"This repo's license (name) isn't an open-source license, so it can't be listed."	The bot found a source-available license, or a standard one with an added restriction, and the message names it.	The same. A dual license only passes if no license file names the source-available one.
"We couldn't find an open-source license..."	Nothing the bot could read named a license. For Learning & Resources, the message adds that CC licenses are accepted there. See below.	Add a standard LICENSE file.

Fixing "We couldn't find an open-source license"

This usually means the license exists but is written in a way no tool can read: a custom preamble, a reworded MIT, or a mention buried in a docs folder.

1. Pick a license at choosealicense.com and copy its text unchanged. Only fill in the year and the name.
2. Save it as LICENSE in the root of the repo, on the default branch.
3. Open the repo page and check that the license now shows in the sidebar. GitHub can take a few minutes to update it.
4. Submit again.

Can't change the repo because it isn't yours? Open an issue on that repo asking the maintainer to add a standard LICENSE file. Most say yes.

7. A real README

The repo needs a README, and that README needs at least 300 characters of actual prose. That's a short paragraph. The bot doesn't count headings, code blocks, images, HTML tags or link addresses, though it does count a link's text. A README that's only a title, a badge row and an install command fails.

Fix: write a paragraph or two about what the project does, who it's for and how to start using it.

8. A repo description

The one-line description in the repo's About box, on the right of the repo page. It's separate from the description you type into the form, though the bot falls back on it if yours breaks the description rules.

Fix: select the gear icon next to About on the repo page and add a sentence.

9. Not marked deprecated

The bot looks for "deprecated", "unmaintained" or "no longer maintained" in two places.

• The repo description. Any of those words, anywhere, counts.
• The first 500 characters of the README. Here the bot only looks for lines that say it about the project: a line starting "Deprecated", a "Status: unmaintained" line, "This project is no longer maintained", or "(deprecated)" in the title. So "drops support for deprecated APIs" in a README is fine.

Fix: if the project is maintained, reword the description or that README line.

10. At least 2 of 7 extras

These are the signs a project expects other people to use it. Any two will do.

Extra	What counts
A topic	At least one topic on the repo, set under About
A CONTRIBUTING guide	A CONTRIBUTING file GitHub recognises in its community profile
A code of conduct	A CODE_OF_CONDUCT file GitHub recognises
An issue or pull request template	An issue or PR template GitHub recognises
A SECURITY policy	SECURITY.md in the root, .github/ or docs/
GitHub Actions workflows	At least one file in .github/workflows/
A release	A published GitHub release. A tag on its own doesn't count.

The bot's message lists the extras it didn't find. If you already have one, it asks for one more.

Fix: the quickest are a topic or two (about 10 seconds) and a release. GitHub's Insights > Community standards page shows which community files you already have, and it can add templates for the rest.

After you're listed

The weekly health check doesn't re-run this whole list. It watches for a smaller set of problems: a repo that disappears or is taken down, is replaced by a different repo at the same name, loses its license or README, gets archived, calls itself deprecated, or goes a year without a push. Removal Policy explains what happens then.