[enhancement] use a popularity metric instead of total number of downloads
Nobody has claimed this yet.
- Dominant language
- HTML
- Stars
- 358
- Forks
- 470
- Avg merge
- 1d 5h
- Merged PRs (30d)
- 7
Description
[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
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the existing total-downloads metric described in the issue, along with the attached screenshot and discussion. Done would require an agreed popularity definition and implementation scope; the issue currently names no files, tests, or entry points.
Written by the indexing model from the issue text.
Assessment
- Domain
- analytics
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100