anuraghazra
Feature Proposal: More stats for repo/pin cards
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
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
- Understand requirements thoroughly
- Research best practices and similar solutions
- Design before implementing
- Write tests first (TDD)
- Implement incrementally
- Document clearly
- 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! 🙌
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?
https://github.com/anuraghazra/github-readme-stats/pull/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
- Understand requirements thoroughly
- Research best practices and similar solutions
- Design before implementing
- Write tests first (TDD)
- Implement incrementally
- Document clearly
- 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!
@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
Those are some great ideas!
I would like to add that average star count by repo would be good as well. It can be obtained by total_stars/total_repo_count. It can also include or exclude forks, archived repos.
@hstsethi good suggestion - i think if you want this to get attention you should thumbs-up the original ~~issue~~ post on this issue thread, but it would be nice to hear from the maintainers about the current status of the repo - i don't see a non-bot created PR merged in over a month, so I'm not sure. Anyway, I've got my own fork going with a lot of pin/repo card-related enhancements if you want to check it out - i also kind of think that API changes and UI/theme changes maybe should be decoupled, it might make it easier for people to maintain forks that add their own functionality and still make it possible to eventually reconcile the fork and the upstream.