After a few weeks of effort, I've completed the curation of all nimble packages
and I've added extra information to the package descriptions. Particularly,
there are now new optional fields like `long_description`, `code_quality`,
`doc_quality`, `project_quality`, `categories` that can be set in
`packages.json` and used by nimble to search or list packages.
For instance, search all packages related to hash functions. How many of them
mention "hash" in the description or tags?
$ nimble search hash | grep -E "^[-_a-zA-Z0-9]+:$" | wc -l
29
Run
How many of them mention "hash" in the description or tags, or the long
description?
$ nimble search hash --full | grep -E "^[-_a-zA-Z0-9]+:$" | wc -l
41
Run
How many of them have a maturity over 2, meaning that there is minimal
documentation and code is readable?
$ nimble search hash --full --mat=2 | grep -E "^[-_a-zA-Z0-9]+:$" | wc -l
31
Run
Adding these features to nimble forced me to break the structure of the
previous `package.json` file. I've tried to find relevant long descriptions
about packages in the packages documentation, when I did not have to spend a
long time. If it took me too much time, and some package authors are not good
at describing their work, I let it empty, meaning that these packages will be
less searchable than the ones with more descriptions.
Similarly, I've classified the packages into 25 categories: `Algorithms`,
`Audio`, `Cloud`, etc. See the full list in the
[documentation](https://github.com/pmetras/packages/blob/extended_info/README.md).
A package can pertain to multiple categories, and sometimes it was not easy
determining where a package fit.
Here is a list of categories with the number of packages associated with each
category:
Category| Number of packages
---|---
*Dead*| 55
Algorithms| 175
Audio| 35
Cloud| 12
Data science| 20
Database| 50
Development| 91
Education| 5
FFI| 287
Finance| 10
GUI| 60
Games| 51
Hardware| 32
Image| 49
JS| 32
Language| 55
Maths| 54
Miscellaneous| 146
Network| 72
Reporting| 28
Science| 22
System| 70
Tools| 80
Video| 19
Web| 91
Last, I've estimated the maturity of the package based on 3 indicators:
`code_quality`, `doc_quality` and `project_quality`. These indicators are in
the range [1 .. 4], with 1 being the lowest quality and 4 the highest. I've
estimated these values based on a few glances at the code, looking at issues or
contributors, reading the documentations, etc. These indicators are subjective
and depend highly on the mood I was when I looked at a package, even if I tried
to keep a scientific evaluation methodology... Again, see the
[documentation](https://github.com/pmetras/packages/blob/extended_info/README.md)
for the ratings used.
If you, as the author of a nimble package, disagree with the description or the
maturity ratings I gave to your package, you have the opportunity to change
these metadata before I generate the final version of `packages.json`. You are
the best one to know exactly what your package is doing and I expect you can
objectively explain it and rate it. In order to do that, just go to the [Google
Sheet](https://docs.google.com/spreadsheets/d/1HWy2YumMMcgEDHk34ACauuWR5TYDJTRUVQ6B-LuRXCs/edit?usp=sharing)
and change the information. **On September 22, I 'll generate the final
version of** `packages.json` for inclusion into [nimble
packages.](https://github.com/nim-lang/packages).
The Google Sheet is sorted on the `url` field and you should be able to find
your packages from your Github/Gitlab or bitbucket account. Don't change the
sort order while others are editing the file.
Thanks
