Methodology
How repositories enter the catalog, how they are classified, and how every number on the site is calculated.
Discovery
Scheduled jobs collect candidate repositories from several independent sources. Each repository records every source that surfaced it and when.
- GitHub search. A rotating set of queries for newly created repositories with early traction, recently pushed young repositories, topic tags such as
mcp-serverorself-hosted, languages, and category keywords. Queries page through results across runs so no single ranking dominates. - Community submissions. Always reviewed by an editor before listing.
- X (when enabled). GitHub links in public posts found through the official X API. We store the post id and author handle for attribution, never the post text.
Duplicates are merged using GitHub's permanent repository id, so a renamed repository keeps its history and its old URL redirects.
Classification and summaries
Each repository gets one primary category, up to three secondary categories, and tags. When a language model is configured, it reads the repository description, topics and a README excerpt and returns structured output that is validated against a strict schema. Repository text is treated as untrusted data: instructions inside a README are ignored. When no model is configured or the model fails, a deterministic keyword classifier is used. Every page states which method was used and its confidence, which is an estimate.
Editors can correct any category or summary; corrected records are locked against automatic reclassification.
Measured growth and trends
Happylancing Directory stores snapshots of star and fork counts on a schedule. Growth over a window (7 or 30 days) is the difference between the latest snapshot and the snapshot closest to the start of the window. A growth figure is shown only when the two snapshots span at least 75% of the window, and the actual span is always displayed. Repositories without enough history show "Not enough history" instead of an estimate. Days without a snapshot appear as gaps in light curves; they are never interpolated.
The trend score combines absolute weekly growth (logarithmic) with growth relative to the repository's size, then scales by quality so that spam with bought stars ranks lower. Repositories with no valid measurement have no trend score and do not appear in trending lists.
Quality score
Raw star count is never the only signal. The quality score is a weighted average of these signals, multiplied by a spam-risk penalty. The current weights are:
| Signal | Weight |
|---|---|
| Stars (logarithmic) | 0.30 |
| Forks (logarithmic) | 0.10 |
| Documentation completeness | 0.20 |
| Has a license | 0.10 |
| Has a description | 0.05 |
| Classification confidence | 0.10 |
| Recent pushes | 0.10 |
| Recent release | 0.05 |
| Spam-risk penalty (multiplier) | 0.60 |
Spam risk is estimated from observable signals only: missing description or README, forks, templates, topic stuffing, placeholder names and known spam phrases.
Sponsorship and affiliates
Sponsored placements are served from a separate table into separate, labeled slots. They are not an input to any ranking function. Affiliate links appear only where an editor has configured them, always with a disclosure next to the link, and repository links are never rewritten into affiliate links.
Known limitations
- GitHub search returns at most 1,000 results per query, so discovery relies on many narrow queries rather than one broad one.
- Snapshot frequency depends on the deployment's schedule; newly discovered repositories need about a week before a 7-day growth figure exists.
- Generated summaries can be wrong. Check the repository before relying on it.