lowlighter/metrics

New plugins ideas

Closed this issue · 6 comments

lowlighter commented

This is a memento to remember cool ideas to implement. If you want to suggest ideas, you can comment below :)

  • Interests / Topics
    Seems there are no GitHub api to retrieve starred topics, but it could be possible to make a plugin which fetch them with puppeteer from github.com/stars/username/topics. Also from this page it's possible to get stars by languages, thus deducing most followed languages by the user

  • Projects
    It's possible to retrieve projects of an user, so it would be possible to add a new section which display projects with their progress, todo/in progress/done tasks.

  • Isometric-contributions
    isometric-contributions looks pretty cool although it's a chrome extension. Maybe it's possible to generate them with actions and integrate it as plugin ?

  • Gists
    Since Gists was removed for Total disk use, these metrics are now unused. Got to add them back somewhere

  • Most productive days and Most productive hours
    Similarly to waka times

  • Twitter integration
    Something like displaying last tweet ? Plus twitter can be associated to github account si it wouldn't be difficult. Check whether twitter api is easy to integrate else use puppeteer

  • Display available for hire (in base "header")
    Use isHireable from user

  • Rss feed
    Maybe some kind of rss feed displayer for generic source ?

Napolitain commented

Could this (languages and commits stats) includes organization owned repositories also? Like, for example user-university organization. It would be neat!

Update : option for excluding languages could be nice too (html, css and markup languages overall)

  • 👍1
Napolitain commented

Other thing, also related languages stats, could we get an option to disable specific repositories?

lowlighter commented

Hi !
Thanks for the suggestions 👍

Options for skipping languages and repositories should come soon (probably later today on master).
For organizations, I'll check it out too when I have some time 🙂

  • 👍1
Napolitain commented

Also having looked a bit into the GraphQL query, it seems you process languages proportion for owner repository.
Do you think it would be interesting to use commits instead of repositories as a source, so we get data from organizations and other users repositories + filtering what you actually coded in X repository from other users ?

I found this : https://github.com/jimkang/get-user-commits

I think that despite the quite important changes in logic, it would allow much more accurate languages statistics for OWNER repositories as well as allowing outside repositories without more work. 😅

UPDATE: it would also allow to get contributions to a fork without counting what has been done by others!

lowlighter commented

Commits stats shoud already be accurate since it uses directly the totalCommitContributions and restrictedContributionsCount which include all user contributions across GitHub, including on non-owned repositories.

For repositories stats, I think I set the query to isFork: false, ownerAffiliations: OWNER because I thought that it was a bit blurry about who own the stats (stars, watchers, releases, etc.) when they're shared among members, but I agree users should be able to include shared stats and forks, so I'll implement it later. Or maybe creating a new section for organization-related repositories could be a good idea so it doesn't mix everything.

As for languages stats, I think it's actually a been trickier.

Currently the languages stats are obtained from the repositories queried objects. So I agree it does not reflects accurate stats, since it actually reflects the most used languages on your repositories instead of what you've really coded, but it's straightforward.

Using commits as a source could be a solution to get more accurate stats, but I can't think of some easy way to achieve it.

languages stats are not available on per-basis commit from what I know, and to get diff/files changed I'm pretty sure you'll need to consume an additional requests, which would triggers the rate-limiter of GitHub pretty quickly, plus, github/linguist would still need to be run manually after this to get languages proportions.

I can see a workaround by directly cloning each repo and using git log --patch --author=user and performing the github/linguist on each patch, but it doesn't seem to scale well, especially with users with large repos, unless coupled with some sort of cache system to monitor only updated repos since last run.

So I don't think it would be easily possible atm, but I'm open to implementing it if someone has a better way to achieve it 👍

lowlighter commented

These are now tracked here.
Don't hesitate to open new issues to suggest new ideas 🎉 !