The `..._quality` variables were probably bad named as English is not my native language and I couldn't figure out better terms.
Based on people feeling uncomfortable with these variables and indirectly with the package maturity indicator, I'm going to remove this information from the packages list. At this stage of the project, it is easier removing something than adding a missing information. Including it into the `packages.json` file had a negative impact on the maintenance of that file as it is dynamic information. But now we lose the ability to judge the _value_ of package (put into the term _value_ the basic meaning from the decision grid I've published or the one you imagine). For instance, we won't be able to find which projects are dead (well, we still can with the `*Dead*` category, 55 out of 1040 packages) or which packages are worth including in a "Nim distribution". This seemed important to me as many packages are of poor quality (that's a personal jugement) and newcomers to the Nim environment could feel deceived as the language itself aimed at code efficiency and performance. A last comment on these quantitative variables: > Doc comments for the public API of a module are of course mandatory except > for obvious cases. On the documentation measurement, everybody has her own standard for documentation. In this forum, lack of documentation is a constant recrimination by newcomers and old nimers. That's the reason I thought that having at least one public `proc` documented was a mandatory minimum to get above 2 in `doc_quality`. It did not seem to me an impossible target to reach for package authors... As I'm going to remove these quantitative variables, this should not be a problem anymore. Let's talk now about the other _improvements_ I've added to nimble. The only one implemented at the present time is the `--full` option that displays an extended description (the values in column "long_description" in the Google Sheet) with the `search` and `list` commands. I've tried to find descriptive sentences of the main package features from the package documentation. Sometimes, even if the package has a long documentation, I was unable to extract a short description as the documentation is not really user oriented or synthetic. For these situations, **I would love package authors to write a short introduction about their packages into the long_description column in the** [Google Sheet](https://docs.google.com/spreadsheets/d/1HWy2YumMMcgEDHk34ACauuWR5TYDJTRUVQ6B-LuRXCs/edit?usp=sharing). This makes their work searchable into nimble. As an example, let say you want to find a web server written in Nim. `nimble search web` will return a list of packages including microasynchttpserver, mofuw or nimhttpd. Have you spotted that httpbeast is not part of the results, nor httputils or whip? You can find them with `nimble search --full web`. The other information added is the categories but they are not used by nimble. They could be used as search filter too or in a packages browser in the future. _PS: I had to revert to the version of the Google Sheet as of September 13th, as someone deleted the "long_description" column. If you have updated the data since that date, check that your input is still there._
