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