> > I don't take this personally, I know you had to rate a lot of projects on a 
> > lot of aspects, and maybe a 2 is deserved here, I don't really give it much 
> > weight. But giving official votes to the quality of various aspects of 
> > projects can carry a lot of negative feelings

That's the reason why I ask the package authors to correct the errors I have 
done, in the Google Sheet. They are the best ones to know the value of their 
projects. And even if they over-rate these `..._quality` variables, this will 
only rate the care they put in their projects. It will be indirect measurement 
for "compiles with a recent Nim version" for instance.

Don't see the resulting _maturity_ evaluation as a vote but more as a 
statistics. Yes, statistics can be seen negatively or positively, like grades 
at school, as they synthesize multiple facets of reality in a single number. 
Use it only as an abstract indicator.

Perhaps the names `..._quality` are a bad choice and I changed them a few 
times. In the long term, these `..._quality` variables are planned for removal 
when the _maturity_ can be computed automatically from project repository and 
code analysis.

Reply via email to