[enhancement] use a popularity metric instead of total number of downloads

[Bad3r]

[WIP]

The total number of downloads metric does not really provide useful information to the user at this point. Many plugins that have existed for a long period of time have numerous downloads and stars. This does not mean that the plugin is a high quality plugin or if it's still being actively used by logseq users.

Its best to implement a popularity metric based on how many times the package was downloaded or by number of votes.

Fro example; Popularity can be calculated as the sum of all votes with each vote being weighted with a factor of 0.98 per day since its creation

The idea is still work in progress; this issue is for tracking and discussion purposes

[CharlesChiuGit]

i think that's a more meaningful metric

[hdansou]

The download metric could also exist for the latest version of the package.

Additionally, there is an opportunity for Logseq to prompt the user to trigger the update of plugins. If users are updating and have the latest version of plugins, the count of downloads will be relevant.

A combination of count == usage and popularity == vote will help gage interest and focus with regards to plugins.

[yoyurec]

The download metric could also exist for the latest version of the package.

so if i'm a good plugin maintainer and update it few times a week - my "latest package" counter will be close to 0 ))))) in other hand old, buggy, unsupported plugins will have 1xxx in counter 🤔

[stdword]

There is another bad point in current downloads metric: If I release a small but frequent plugin versions and users has turned on auto update: total number of downloads will grow, while total number of users will be the same.

v1.0.0: 100 users v1.0.1: 100 users

but downloads count is 200