Feature Proposal: More stats for repo/pin cards

[hesreallyhim]

Is your feature request related to a problem? Please describe.

There is a lot of data that you can gather about a repository itself besides its star count and number of forks. As opposed to thinking of a repo card as something that is sort of intrinsically related to a user, I'd like to have a proper "repo stats" card with more metrics - # of open issues, # of open PRs, age of repo, average age of open Issues, etc. - these are all meaningful indicators about the health of a repo itself.

Describe the solution you'd like

In #4617 I've added three additional metrics to the repository/pin cards - number of open issues, number of open PRs, and age of repo. I've done this in the most minimal way I could, and it only affects the API. But as I started writing up the PR, it occurred to me that in principle a repo card could be given "first-class" status - more metrics, more customization, more flexibility for styling - effectively as flexible as the stats cards are. To me, this is something I would really be keen to know about, and to have available.

Describe alternatives you've considered

?? I've intentionally made the PR as un-opinionated as possible because I want to know how the maintainers and the users think of repo/pin cards - are they "extras" that are not the main focus of this project, or would people be interested in having cards about repos per se. Even calling them "pins" suggests that their purpose is to be pinned onto a USER's personal profile/README, rather than showing first-class metrics about a repo itself.

Additional context

No response

[tysoncung]

Thanks for opening this issue! I'm interested in contributing to this. 👋

🤔 Understanding the Requirements

To provide the best solution, I'd like to understand:

Context:

• What's the current behavior?
• What's the expected/desired behavior?
• What's the impact or use case?

Scope:

• Are there any specific requirements or constraints?
• Any preferences for implementation approach?
• Related issues or PRs?

Success Criteria:

• What would "done" look like for this issue?
• Any specific metrics or tests needed?

💪 How I Can Help

I have experience with anuraghazra projects and can contribute:

• 🔍 Investigation: Research and propose solutions
• 💻 Implementation: Write clean, tested code
• ✅ Testing: Comprehensive test coverage
• 📚 Documentation: Clear docs and examples
• 👀 Review: Iterate based on feedback

🚀 My Approach

1. Understand requirements thoroughly
2. Research best practices and similar solutions
3. Design before implementing
4. Write tests first (TDD)
5. Implement incrementally
6. Document clearly
7. Iterate based on review

Let me know if this is still open and how I can help! I'm excited to contribute. 🎯

My relevant experience:

• Similar projects and features
• Modern development practices
• Open source contribution
• Production system experience

Feel free to assign this to me if you'd like me to work on it! 🙌

[hesreallyhim]

Thanks for opening this issue! I'm interested in contributing to this. 👋

🤔 Understanding the Requirements

To provide the best solution, I'd like to understand:

Context:

• What's the current behavior?

repo/pin cards are very limited with respect to customization and the data they expose - also i think the data is mostly/somewhat about a specific user's relation to that repo, i'm not totally sure. compared to the stats cards, they don't offer much to the user.

• What's the expected/desired behavior?

expose cards that are about repos per se - expose more data points (i can think of loads), maybe come up with a grading system for the health of a repo. introduce style customizations as dynamic as for stats cards.

• What's the impact or use case?

provides a detailed source of information about a repo. for me, i maintain an "awesome" list, so i use it to display stats about the repos i share. for other people, maybe they want to have cards about their own repos that are way more fine-grained. the semantics of the term "pin" suggests that a repo card only exists in the context of a user's profile.

Scope:

• Are there any specific requirements or constraints?
• Any preferences for implementation approach?
• Related issues or PRs?

#4617 - i already implemented # of open issues, # of open PRs, age of the repo, and i just added another branch with time since last commit. you can see this in action at awesome-claude-code, where i also added a way to hide the title and the description, because I just wanted the stats. The main things to decide are:

• what stats are most valuable to expose? (being mindful that more complex queries are more "expensive" in terms of rates)
• how should the stats be integrated with the layout?
• what options are there for enhancing/expanding theming for pin cards.

I'm mostly ignorant about the theming part of this repo, so that's where i could use the most help.

Success Criteria:

• What would "done" look like for this issue?
• Any specific metrics or tests needed?

i don't know what the standards of this repo are regarding things like test coverage. probably we would want to measure how "expensive" some of these queries might be from a GraphQL complexity POV.

"done" depends on what goals we set - for me i guess optimally i would like to have repo cards that have complete feature parity with stats cards - maybe there's reasons that have already been discovered why this is challenging, but i'm not aware of them. for me, the idea would be to decouple the repo cards entirely from any individual user (not to say to get rid of the "pins" cards, but to have feature-complete repo cards as well). I mean there are hundreds of awesome-lists out there, so even just for that community i could see a lot of value.

💪 How I Can Help

I have experience with anuraghazra projects and can contribute:

• 🔍 Investigation: Research and propose solutions
• 💻 Implementation: Write clean, tested code
• ✅ Testing: Comprehensive test coverage
• 📚 Documentation: Clear docs and examples
• 👀 Review: Iterate based on feedback

i'm not deeply familiar with this codebase, and as i mentioned i have no familiarity with the UI nuances of it, so if we were to collaborate that would be something very useful to understand. i think i have a pretty good grip on the API side of it, and i managed to set up my own deployment as well.

🚀 My Approach

1. Understand requirements thoroughly
2. Research best practices and similar solutions
3. Design before implementing
4. Write tests first (TDD)
5. Implement incrementally
6. Document clearly
7. Iterate based on review

Let me know if this is still open and how I can help! I'm excited to contribute. 🎯

My relevant experience:

• Similar projects and features
• Modern development practices
• Open source contribution
• Production system experience

Feel free to assign this to me if you'd like me to work on it! 🙌

i'm not a maintainer or even (yet) a contributor to this repo (have just opened a small PR), so i have no idea what to say about "requirements", that's why i wanted to query the maintainers as to whether this fits in with their "vision" of the repo - is this project mainly supposed to provide value to individual users and their profile READMEs? is there appetite for this kind of functionality. i have no idea about that, so very curious to understand better. if it's outside the scope of the project, i think it's worth doing as a hard fork either way, but again i can't say one way or another, i just did the things i wanted to do for my use case, and now i'm trying to see if they can be incorporated into the main repo. i'd be happy to collaborate either way, and obviously this is wildly successful project, so i look forward to hearing from the maintainers and other users. cheers!

[hesreallyhim]

@tysoncung if you're interested in possibly collaborating on this, it might be good to give a thumbs-up here and/or on the related PR, i think that's how they rank issues