I fail to see a reason where it would be a violation because of the following reasons:
1) it's a response to a user's request, i.e., not initiated by the repo author
2) it depends on consensus of the user.
3) it's not automated (most of the items from the policy are related to automation).
4) the repo author has no obligation whatsoever of maintaining the project. He is not paid or forced to do it.
5) if the user really wants to apply this change or disagrees with this practice, he/she can always fork it.
That said, I understand that it may still not feel "fair" compared to other projects that don't follow this practice. Or the feeling of "wanting to help but you're asked to do some things first".
Companies already do that to accept your pull requests though [0], which takes way longer than giving a star - and I didn't see a complaint about it on HN
It's quid pro quo, isn't it. The repo is buying stars with bug reporting as currency.
Which may well be against GitHub rules but more than that, it's a stupid thing to do. Bug reporting helps projects get better. They're blocking real bug reports until they get a star. Seems like self-harm to me.
There's many cases where that's not true and indeed low-quality bug reports hurt the projects from getting better, specially for mid-to-high popular solo projects.
Think about it in more familiar terms, are more job offers good for searching for a job? It might seems so, but only if you think about well-timed high quality offers. Suddenly getting spammed on your email, linkedin, etc. with dozens+ of low-quality job offers would def not be helpful.
> There's many cases where that's not true and indeed low-quality bug reports hurt the projects from getting better, specially for mid-to-high popular solo projects.
So it's ok to report low quality bugs as long as you give stars?
I know that's not your argument, but this is what this thread is about.
Regardless of the current rule, it really ought to be a violation. If it's not, all repos that care about star rankings are forced to start doing the same thing to compete, which eventually turns stars into a metric of which repos have the highest quantity of annoying problems that users want to report, rather than a metric of whatever it's supposed to measure.
If communist China is anything like communist Europe used to be, finding clever ways to overcome the rules or use them to your advantage is almost a sport, and definitely not considered immoral or unethical by most.
This cheats the other users (like me or you) -- if we are looking at the project's star count, you are likely trying to judge project's popularity and get a measure of how many people like it.
And dae's star count is basically a lie - it does not represent how many people liked it, but rather how many people had found annoying bugs in it. Someone who is forced to use dae and hates it would still need to star it. And as you said, other projects who don't have this practice are in disadvantage.
(And that's why I have no problem with things like CLAs, or requiring details bug reports: they are not user-visible and they don't mess with global rating.)
There's a submission regarding CLAs nearly every month. But complains regarding them is not for the time it takes to sign one. Similarly complains about the practice here aren't for the time it takes to star a repo.
1) it's a response to a user's request, i.e., not initiated by the repo author
2) it depends on consensus of the user.
3) it's not automated (most of the items from the policy are related to automation).
4) the repo author has no obligation whatsoever of maintaining the project. He is not paid or forced to do it.
5) if the user really wants to apply this change or disagrees with this practice, he/she can always fork it.
That said, I understand that it may still not feel "fair" compared to other projects that don't follow this practice. Or the feeling of "wanting to help but you're asked to do some things first".
Companies already do that to accept your pull requests though [0], which takes way longer than giving a star - and I didn't see a complaint about it on HN
[0] https://github.com/google/eddystone/issues/258