The place to report packages would be at https://github.com/nim-lang/packages.
But this package just appears to be just no long maintained, not malicious. There are ublock warnings on GitHub or nimble.directory?
Appears to be
I could not reach the GitHub from the nimble page
To say the package itself is premature from my side, but the nimble page and the package domain were fishy
but maybe something like last commit date, or new issues since last commit could be a decent proxy
Stable software doesn't need to have new commits/versions or issues if it functional.
Second this - our best packages are the ones we don't have to change - many of the packages we use the most don't have commits for months/years - nim-results for example (which certainly has a lot of users) was last touched 8 months ago.
That said, if you follow reverse dependencies you can get a slightly better proxy - ie you can consider the most recent commit over the dependency graph - this would accurately show a package like nim-results as being "recently" useful.
In my experience the quality of a package can be judged quite effectively by knowing its author(s)...
I suggest we add a whitelist of trusted authors to Nimble/Atlas and then these packages get a recommended annotation in the list of search results.
It may be simple but it's also forge dependent in a way that nimble and atlas aren't.
It artificially penalizes packages that aren't hosted on github (or forges with similar github ui/apis like codeberg/forgejo)
I think a more generalizable and useful metric for libraries would be similar to what @arnethduck suggested above which would be based on dependency graphs.
In other words, an option to sort libraries by the number of dependents.
If I'm looking for a package to use with nim it's because of I have a particular problem not just randomly looking for reasons to introduce new dependencies I have to manage.
So it's something that make more sense when comparing categorically similar packages (I'm never comparing adding results vs adding some terminal library (Technically, I wouldn't have to find one of those I have my own, bugs and all :P))
But your point still stands that the more low-level a package is the more-likely it is to have dependents. Also, I think there is a good chance a lot of folks don't submit binary only packages to the registry which would lead to pretty specious data in the first place (at least I don't usually unless I'm advertising it to the nim community specifically).