From 92180242004d928612e2fc0a07a39bf2e6f64e4c Mon Sep 17 00:00:00 2001 From: Vinta Chen Date: Sat, 15 Aug 2026 13:11:04 +0800 Subject: [PATCH] docs: fold serves-Python-developers scope test into ADR-0001 Per maintainer choice, the new scope test replaces the old primarily-written-in-Python (>50%) requirement: implementation language and packaging no longer matter as long as Python developers use the thing in their Python work (e.g. uv and ty are Rust; agent skill packs are markdown), while pure-Python projects nobody uses in Python work still don't qualify. Folded into the existing ADR rather than filed as a separate one. Co-Authored-By: Claude --- docs/adr/0001-shortlist-not-catalog.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/adr/0001-shortlist-not-catalog.md b/docs/adr/0001-shortlist-not-catalog.md index 20c57757..92812ce4 100644 --- a/docs/adr/0001-shortlist-not-catalog.md +++ b/docs/adr/0001-shortlist-not-catalog.md @@ -8,7 +8,7 @@ By mid-2026 the list held 576 entries across 75 sections, with entry inflow up 2 ## The decision -Each Use Case (a subcategory, or a flat section) lists at most its Obvious Choices — up to 3, plus up to 2 marked Challengers, hard maximum 5 (numbers provisional, to be reviewed after the prune). Admission is by maintainer editorial judgment, informed primarily by PyPI download counts rather than GitHub stars, and stated as final; judgment overrides the signal's known failure modes (CI/dependency-inflated counts, model releases consumed as weights rather than pip installs, large-but-specific audiences misread as "niche"). Once a Use Case is at cap, the only way in is Displacement: the PR names the entry it replaces and argues the newcomer does that job better. Use Cases are defined by the list's existing structure; an entry PR can never create the subcategory it needs. Standard-library entries hold a slot only where the stdlib module is itself the obvious choice. The existing stock gets the same test retroactively: a staged, worst-first prune (per-section sweep commits), with removed entries deleted outright — git history is the archive. Resources sections (Newsletters, Podcasts, Websites) are out of scope for now. +The list's scope test is "serves Python developers", replacing the old "primarily written in Python (>50%)" requirement: implementation language and packaging are irrelevant when Python developers use the thing in their Python work (uv and ty are Rust; agent skill packs are markdown), while a pure-Python project nobody uses in Python work does not belong. Each Use Case (a subcategory, or a flat section) lists at most its Obvious Choices — up to 3, plus up to 2 marked Challengers, hard maximum 5 (numbers provisional, to be reviewed after the prune). Admission is by maintainer editorial judgment, informed primarily by PyPI download counts rather than GitHub stars, and stated as final; judgment overrides the signal's known failure modes (CI/dependency-inflated counts, model releases consumed as weights rather than pip installs, large-but-specific audiences misread as "niche"). Once a Use Case is at cap, the only way in is Displacement: the PR names the entry it replaces and argues the newcomer does that job better. Use Cases are defined by the list's existing structure; an entry PR can never create the subcategory it needs. Standard-library entries hold a slot only where the stdlib module is itself the obvious choice. The existing stock gets the same test retroactively: a staged, worst-first prune (per-section sweep commits), with removed entries deleted outright — git history is the archive. Resources sections (Newsletters, Podcasts, Websites) are out of scope for now. ## Considered options