Skip to content

Conversation

@hesreallyhim
Copy link

@hesreallyhim hesreallyhim commented Oct 23, 2025

Description

This PR extends the API for the repo pins to expose the following metrics:

  • # of open Issues
  • # of open PRs
  • Age of the repo

These are exposed via additional query parameters for the /pins? endpoint, including:

  • show_issues
  • show_prs
  • show_age

There are also some convenience parameters:

  • all_stats - short-hand for ?show_issues=true&show_prs=true&show_age=true

There is also one more query param at the moment:

  • stats_only - this is used on awesome-claude-code to render a single-row card with just the repo's stats (hides the title and the description).

But on reflection, I'm inclined to drop this - I think this a matter that deserves a statement from the maintainers (unless this ground has already been covered) about how they envision the repo cards in relation to the user stats. Because of my own particular use cases, I am very interested in seeing a card that gives detailed stats about a repository - whereas, it seems like the posture of this repo is mostly to give stats about a user, and that repo cards are "second-class citizens", e.g. with respect to their customizability, the metrics that are fetched about them, and so on. I am curious to know the etiology of this state of affairs, and whether the maintainers are keen to accept contributors that "elevate" repo cards to be as flexible and informative as stats cards, or whether perhaps that should be done in a hard fork.

In the readme, I've sketched the query parameters as I've implemented them, and as they are used in awesome-claude-code, but it occurs to me that they could just as well have an API that is much more similar to the stats cards, with e.g. a dynamic "show"/"hide" param that could even encompass the number of forks and stars.

So, after formulating this PR, which I conceived of as a contribution to the (wonderful) github-readme-stats project, it's dawning on me that the repo in its current form is much more focused on user stats than repo stats. For me, having something which is an indicator of the "health" or strength of a repository itself (how many open Issues does it have, even including more metrics like average lifespan of an Issue, etc.) is in itself really valuable.

In any event the current PR is extremely modest and is ONLY meant to touch the api/fetching/query-string-parsing parts of the codebase. I'm not familiar enough with the "themes" workflow to know whether this would even be adopted by people who frequent this repository. The three metrics I've added are such that they could easily be added to the existing "default" horizontal layout on the bottom right (or so it seems to me).

Do the maintainers have a stance or opinion about whether expanding the scope of the repo and/or gist cards is something that they see part of this project or as a "sister" project? Is this something that we can get feedback about from the community? I would be happy to take a hard fork that really juices up the repo cards, but maybe this isn't of much interest to people, I'm not sure.

For a very sketchy draft implementation of how these stats might be added to a card, see hesreallyhim#13.

@vercel
Copy link

vercel bot commented Oct 23, 2025

Someone is attempting to deploy a commit to the github readme stats Team on Vercel.

A member of the Team first needs to authorize it.

@github-actions github-actions bot added documentation Improvements or additions to documentation. repo-card Issues related to the pin/repo card. labels Oct 23, 2025
Comment on lines +26 to +28
hide_title,
hide_text,
stats_only,
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably remove these

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation. repo-card Issues related to the pin/repo card.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant