chore: run docvet on flagship open-source projects for visibility

[Alberto-Codes]

Summary

Run docvet against high-profile Python open-source projects (FastAPI, Pydantic, etc.) to demonstrate findings, validate the tool at scale, and potentially open PRs that showcase docvet's value.

Motivation

The adoption playbook from ruff, black, and pytest shows a common pattern: flagship adoption by marquee projects creates social proof. Ruff's adoption by FastAPI, Pandas, and Airflow was a turning point.

For docvet, running checks on popular projects serves multiple purposes:

1. Validates the tool — proves docvet works on real, large codebases
2. Generates compelling content — "We ran docvet on FastAPI and found X stale docstrings"
3. Opens PR opportunities — fix real docstring issues, credit docvet in the PR
4. Creates word-of-mouth — maintainers who see value may adopt docvet

Target projects (Google-style docstrings + mkdocs/mkdocstrings)

• FastAPI (mkdocs-material, high visibility)
• Pydantic (mkdocs-material, high visibility)
• typer (same author as FastAPI, mkdocs-material)
• httpx (mkdocs-material)
• Polars (mkdocs-material, growing rapidly)

Approach

1. Run docvet check --all on each project
2. Document findings (counts by rule, interesting examples)
3. If findings are genuine and fixable, open small PRs fixing 5-10 issues
4. Blog post or docs page: "What we found running docvet on the Python ecosystem"

Related

• docs: define competitive positioning against pydoclint and landscape #162 (competitive positioning — flagship results validate the positioning)
• chore: audit and expand GitHub/PyPI discoverability metadata #156 (discoverability — blog post drives traffic)