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

How many of them mention "hash" in the description or tags, or the long 
    $ nimble search hash --full | grep -E "^[-_a-zA-Z0-9]+:$" | wc -l

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

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 
 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| 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 
 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 
 and change the information. **On September 22, I 'll generate the final 
version of** `packages.json` for inclusion into [nimble 

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.


Reply via email to