I don't think that open issues/LoC is very relevant since some languages despite doing a lot in few lines of code(or even characters) still require an amount of mental effort similar to more verbose languages.
I very much like how GitHut used issues/commits. In my interpretation:
(1) If your project has a lot of commits and few issues it has a very high quality.
(2) If your project has a few of commits and many issues it has either very low quality or is not being developed.
(3) Having a lot of commits and a lot of issues and vice versa is kinda expected, since new features(commits) often introduce new bugs and small projects often have few of both.
When you cross that with popularity(new forks, new watchers) over the years you can narrow (2) with some confidence.
Using that approach is trickier when it comes to comparing languages, but the data GitHut gives seems to be in line with common knowledge, at least when it comes down to open source software and and when you compare the most popular languages.
Not so sure about that. Lots of commits and few issues could mean that it's cool or interesting somehow, but isn't actually being used for much. Vice versa for few commits and many issues.
Hard to say much for sure without breaking down the details, who's discovering the issues, how many are real, how many are serious/blockers versus minor annoyances with workarounds or feature requests, are the commits new features, bug fixes, refactoring, etc.
The point I am(should be) trying to make is that, the graphs tell us a lot more about how the projects on each language are developing than it does about the individual merits of the language it self.
I very much like how GitHut used issues/commits. In my interpretation:
(1) If your project has a lot of commits and few issues it has a very high quality.
(2) If your project has a few of commits and many issues it has either very low quality or is not being developed.
(3) Having a lot of commits and a lot of issues and vice versa is kinda expected, since new features(commits) often introduce new bugs and small projects often have few of both.
When you cross that with popularity(new forks, new watchers) over the years you can narrow (2) with some confidence.
Using that approach is trickier when it comes to comparing languages, but the data GitHut gives seems to be in line with common knowledge, at least when it comes down to open source software and and when you compare the most popular languages.