Andrew Nesbitt

Moving this to the [Backlog](https://github.com/librariesio/libraries.io/blob/master/Backlog.md) as we'd still like to implement it but can't see that happening in the near future.

The initial pass at implementing SourceRank 2.0 will be focused on realigning how scores are calculated and shown using existing metrics and data that we have, rather than collecting/adding new...

There are a few places where the sourcerank 1.0 details/score are exposed in the API that need to be kept around for backwards compatibility: - ProjectSerializer - the `rank` field...

Starting to implement bits over here: https://github.com/librariesio/libraries.io/pull/2056

One other thing that springs to mind, the first pass of the implementation will focus at a project level and only really considers the latest release. Then we'll move on...

Making good progress on filling in the details of the calculator, current approach for scoring is to take the average of the different categories scores and for each category take...

Example of the current breakdown of implemented scores: - overall score: 88.7 - popularity_score: 80 - dependent_projects_score: 70 - dependent_repositories_score: 90 - community_score: 99 - contribution_docs_score: 99 - quality_score: 87...

Things to think about soon: - How to calculate, store and show the change in score for a given category over time - How to visualize what goes into a...

Added an actual method to output the breakdown of the score: ```json { "popularity": { "dependent_projects": 0, "dependent_repositories": 0 }, "community": { "contribution_docs": { "code_of_conduct": false, "contributing": false, "changelog": false...

Thinking about dependency related scores, here's my current thinking: - one score for the average source rank score for every top level runtime dependency - if a package has zero...