docs: add description style rule and audit check

CONTRIBUTING.md had no description style rule and audit-the-list never read descriptions, so verbatim taglines with grammar, hyphenation, and capitalization errors stayed in README.md.

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Vinta Chen
2026-10-28 08:29:11 +08:00
co-authored by Claude
parent 91479c676e
commit 09e8e0f116
2 changed files with 5 additions and 1 deletions
+1 -1
View File
@@ -27,7 +27,7 @@ Done when every entry in scope has downloads (or a stated no-signal reason), rep
## 3. Verdicts
Draft a verdict and reason for every entry, restructure before cap: decide Splits, mints, and re-homes first — cutting before restructuring destroys entries — then apply the cap tier by tier, including promotions and demotions between obvious choice and challenger. Ground every reason in the fetched evidence; label anything unverifiable as a judgment call. Where fresh evidence contradicts the standing verdict, say so in the reason instead of silently keeping the seed. A proposed addition under `docs/audit-logs.md` "Rejected Additions" seeds as reject from that line.
Draft a verdict and reason for every entry, restructure before cap: decide Splits, mints, and re-homes first — cutting before restructuring destroys entries — then apply the cap tier by tier, including promotions and demotions between obvious choice and challenger. Ground every reason in the fetched evidence; label anything unverifiable as a judgment call. Where fresh evidence contradicts the standing verdict, say so in the reason instead of silently keeping the seed. A proposed addition under `docs/audit-logs.md` "Rejected Additions" seeds as reject from that line. Check every description in scope against CONTRIBUTING.md Description Style, since taglines copied verbatim often break it; put each fix in its row's reason as old and new text, so the maintainer reviews it with the verdict.
## 4. Review and go
+4
View File
@@ -57,6 +57,10 @@ Use the **PyPI package name** as the display name so developers can copy it dire
Aim for a rendered line of 100 characters or fewer: the name, ` - `, and the description, not counting the URL. Lines that long fit on one line in the GitHub README, which starts wrapping them around 105. This is a soft cap. When a draft lands near 105, cut filler words to get under it; when the content needs more room, let the line wrap rather than drop meaning.
### Description Style
Write descriptions in sentence case with correct grammar. Proper nouns keep their capitals, and compound modifiers before a noun take hyphens: "A cross-platform Bluetooth Low Energy client", not "A cross platform Bluetooth Low Energy Client". A project's own tagline is no exception: when it breaks these rules, fix it instead of copying it.
### Standard Library Module
```markdown