reduce the weight of issue-related factors (open issues, issues distribution)

[spelunk]

It sounds like a great idea to look at GitHub issues, but in practice many projects use the issue tracker to also keep track of long-term projects and discussions. It's preferable to have one open issue that people can +1 rather than have people flood an issue tracker with new issues repeating the same request. Should the weight of the issue tracker be reduced?

[satazor]

Oops didn't mean to close it.

[spelunk]

heh. Question still stands: given that projects handle issues differently, does it make sense to give such a large weight to Github issue statistics?

[satazor]

I think that the issues metric needs to be improved. The most important factor for that metrict should be the time it takes for a contributor to respond to an issue, but doing that would increase exponentially the number of calls to the GitHub API and that's a no-no :/

For now, maybe we can decrease it's weight but I need to so some extensive testings to find the right balance.

[7PH]

Hey,

The most important factor for that metrict should be the time it takes for a contributor to respond to an issue

I also think that issues created by collaborators should also have no or less impact on the score, because some projects are using issues as task-lists, and it seems to me that issue tracking usage is better than direct pushes to master.

[mikaello]

Another angle of evaluating issues are the labels. The maintainer can change the existing labels or add new ones, but my impression is that many uses the default ones (or at least in addition to any custom ones). And issues labeled with enhancement are not necessarily a bad sign, more that there are plans for that project.

Awareness of NPMS's logic of penalizing open issues may incentives the maintainer to quickly close these issues with a comment, instead of letting them stay open and more accessible.