github-readme-stats
github-readme-stats copied to clipboard
anuraghazra
Improve ranking system
Describe the bug I was interested in how the rank was calculated and wanted to know how to rank up. I found out that you use a function called normalcdf to normalize the calculated score. Its basically impossible to get a rank below A+ since normalcdf(0, 231, 7) * 100 returns 51.55 which is in the A+ area.
The code can be found here.
TODOS (Added by @rickstaa)
- [ ] Decide on a new grading system, #2265.
- [ ] Create PR that adds this new grading system.
- [x] Merge https://github.com/anuraghazra/github-readme-stats/pull/2116.
- [ ] Merge https://github.com/anuraghazra/github-readme-stats/pull/1186.
- [ ] Create PR that shows the top user percentage on hover (see https://github.com/anuraghazra/github-readme-stats/issues/2157).
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
I think it might be broken in more ways than one.
- The implementation doesn't seem to work right: https://stackoverflow.com/questions/5259421/cumulative-distribution-function-in-javascript/5263759#comment114047028_5263759
- The CDF used is for the normal distribution, which I doubt GitHub stats adhere to. Perhaps a power-law distribution function would be a better fit? https://en.wikipedia.org/wiki/Power_law#Power-law_probability_distributions
Here's another example of the weird ranking behavior: https://github.com/anuraghazra/github-readme-stats/issues/330#issuecomment-689773382
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
I think it might be broken in more ways than one.
- The implementation doesn't seem to work right: https://stackoverflow.com/questions/5259421/cumulative-distribution-function-in-javascript/5263759#comment114047028_5263759
- The CDF used is for the normal distribution, which I doubt GitHub stats adhere to. Perhaps a power-law distribution function would be a better fit? https://en.wikipedia.org/wiki/Power_law#Power-law_probability_distributions
Here's another example of the weird ranking behavior: #330 (comment)
I agree. rank evaluation is not correct and too biased. Sorry but I have no good ideas on how to make it less inaccurate and improve it (i suck at maths) Would love to hear any opinions and possible implementation details.
cc @magneticflux-
@anuraghazra I've made an implementation of one of my ideas in #960 with an explanation inside PR
Just placing this here so we don't forget. As pointed out by #2116, there also is a bug in the current rank implementation that skews the scores.
I think it might be broken in more ways than one.
- The implementation doesn't seem to work right: https://stackoverflow.com/questions/5259421/cumulative-distribution-function-in-javascript/5263759#comment114047028_5263759
- The CDF used is for the normal distribution, which I doubt GitHub stats adhere to. Perhaps a power-law distribution function would be a better fit? https://en.wikipedia.org/wiki/Power_law#Power-law_probability_distributions
Here's another example of the weird ranking behavior: #330 (comment)
I agree. rank evaluation is not correct and too biased. Sorry but I have no good ideas on how to make it less inaccurate and improve it (i suck at maths) Would love to hear any opinions and possible implementation details.
cc @magneticflux-
Hi, To be honest I don't care if my ranking is lowered after the ranking system is updated, but I don't like being stuck at A+ no matter how hard I try... Another year has passed and I see a lot of people coming up with great ideas, maybe it's time to update the ranking system.
@LucBerge and @ZjzMisaka, I agree with you that the ranking needs to be improved. There have been multiple proposals and PRs open that try to improve the ranking:
- https://github.com/anuraghazra/github-readme-stats/issues/2265
- https://github.com/anuraghazra/github-readme-stats/issues/1560
- https://github.com/anuraghazra/github-readme-stats/issues/1579
- https://github.com/anuraghazra/github-readme-stats/issues/455
- https://github.com/anuraghazra/github-readme-stats/pull/960
- https://github.com/anuraghazra/github-readme-stats/pull/1186
I think three things can be improved about the ranking:
- Switch to a more commonly used grading system (i.e. A-F, A+ to F or % based).
- Show top-users percentage on hover (see https://github.com/anuraghazra/github-readme-stats/issues/2157).
- Improve the rank calculation (see https://github.com/anuraghazra/github-readme-stats/pull/2116 and https://github.com/anuraghazra/github-readme-stats/pull/1186).
I asked @anuraghazra for his opinion at https://github.com/anuraghazra/github-readme-stats/issues/2265.
CHANNEL_PINS_UPDATE was discussed in #149. Unsure about WEBHOOKS_UPDATE, as it only provides guild_id and channel_id. Page @AntiTcb for opinions.
Hi @rickstaa, I understand your caution in modifying the ranking system, but I believe that making changes is always good. Can some temporary modifications based on existing ranking system be made before receiving a response from @anuraghazra, at least to change the situation where the ranking is stuck in A+? I think ranking can reflect the changes made by user from the initial state, rather than the gap between users. Therefore, I don't care if my ranking will change to F after the ranking system changes, I prefer to see my progress dynamically. After all, modifying a ranking system cannot satisfy everyone. If you insist on giving everyone a "beautiful" ranking, the system will ultimately become non referential. Thanks.
Hi @rickstaa, I understand your caution in modifying the ranking system, but I believe that making changes is always good. Can some temporary modifications based on existing ranking system be made before receiving a response from @anuraghazra, at least to change the situation where the ranking is stuck in A+? I think ranking can reflect the changes made by user from the initial state, rather than the gap between users. Therefore, I don't care if my ranking will change to F after the ranking system changes, I prefer to see my progress dynamically. After all, modifying a ranking system cannot satisfy everyone. If you insist on giving everyone a "beautiful" ranking, the system will ultimately become non referential. Thanks.
I agree with you. I already started working on this last week. Not only that, but I will merge https://github.com/anuraghazra/github-readme-stats/pull/1186#issuecomment-1537116588 as soon as @francois-rozet has resolved some small issues I had with that pull requests 👍🏻. @anuraghazra can always change it to his liking later.
Just a heads-up. I just merged https://github.com/anuraghazra/github-readme-stats/pull/1186 which, in my opinion, is a great improvement compared to the old ranking. You are welcome to open pull requests if you think the weights can be further improved 👍🏻. There is also a proposal open to change the rank levels. You are welcome to put your ideas in #2265.
Re-opened so that people can provide feedback on the new ranking system and create improvements.
Would be good to update the readme for this project to include an explanation on the ranking system and meaning of the letters.
Would be good to update the readme for this project to include an explanation on the ranking system and meaning of the letters.
You're right! The documentation will be updated when #2749 is merged 👍🏻. You are welcome to suggest any improvements.
So with the new ranking algo, a former ranking of 'S' for 12K plus annualized commits earns a modest ranking of 'B'. My ego may never recover. ;)
So with the new ranking algo, a former ranking of 'S' for 12K plus annualized commits earns a modest ranking of 'B'. My ego may never recover. ;)
I'm afraid you are an outlier 😮. You made as many commits in one year as I did in my whole GitHub career 🔥. In my opinion, PRs are preferred over small commits since it improves code collaboration 🤔. I do understand that this is opinioned and that in some cases it is better to work with commits. Can you maybe check if @francois-rozet new ranking mechanism improves your rank (see https://github.com/anuraghazra/github-readme-stats/pull/2762)?
@objektwerks I checked and #2762 will improve the behaviour. Also by making some pull requests you can increase your rank rapidly.
Old ranks
Available ranks are S+ (top 2.5%), S (top 10%), A+ (top 25%), A (top 50%), B+ (top 75%) and B (everyone). This ranking scheme is based on the Japanese Academic Grading system. It is calculated as a weighted sum of ranks for each statistic (number of commits, pull requests, issues, stars and followers) based on the cumulative distribution function of an exponential distribution. The implementation can be investigated at src/calculateRank.js. The circle around the rank shows the rank completion percentage compared to the maximum rank.
Ranks (after #2762)
S, A+, A, A-, B+, B, B-, C+ and C
@rickstaa Thanks for the explanation and tip!
I tried the #2762 option, which did reflect the ranking circle above -- with one minor difference in total commits. It now reads: Total Commits: 29.4k So the count goes back further than 1 year.
You all might consider 2 rankings -- 1) pr-driven and 2) commit-driven. Just a thought. :) Cheers!
@rickstaa Thanks for the explanation and tip! You all might consider 2 rankings -- 1) pr-driven and 2) commit-driven. Just a thought. :) Cheers!
Hello, I think making a lot of commits should not be a goal. Having 10000 commits (especially if named "fix") that change one or two lines, is a bad development practice. PRs are much better indicators of meaningful contributions.
@francois-rozet Everyone has different development styles. Hence the multi-style ranking suggestion. :)
@francois-rozet Everyone has different development styles. Hence the multi-style ranking suggestion. :)
I agree with @francois-rozet on this one 😅. Although everybody has a different development style, from experience I noticed that these small commits hurt maintainability when working on projects with other people. Nevertheless, since this is an OS (community based) project, if enough people support your idea we might look at it (see https://github.com/anuraghazra/github-readme-stats/issues/1935 for the most popular feature requests) 👍🏻.
@rickstaa
I work alone on multiple projects. And small units of work make sense for my workflow. Not everyone is an OSS warrior. ;)
On a commercial or open source project, with several contributors, developers ideally work in a branch and submit PRs as required. So commit size or frequency is irrelevant. It's the PR process that impacts a project.
Ok, I've said way too much. :) Thanks for the conversation! And all the best with your project. Cheers!