I wonder if this goes against github's "no automated starring" policy [0] (that people have been banned for in the past). Maybe "coordinated inauthentic activity" ?
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.
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.
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.
Craven is definitely one of the words I'm groping for to express just what is wrong with this.
I really don't understand the "seems fair" comments.
I (stupidly I see now) treat the stars as feature just for me, like a bookmark in my own browser. There for my use, not anyone else's.
Obviously that was silly since they are public and anything that is public is someone somewhere's currency, and anything that is currency will expose the lowest of the low human behavior.
And this IS automated. The automation is in the form of a policy rather than a scripting language, but it's still a mechanistic rule where a star is produced by application of an if-this-then-that, and by a transaction, purchased exactly like with money. By at least those TWO different means this is not an honest reflection of a users regard or admiration or expression of value.
Github surely would see that as devaluing stars and harming a feature of their site. Surely github does not want stars to become like amazon reviews.
Are you arguing that people should not be authoritarian on their own personal projects? To me this signals having healthy relationship with the project and knowing how to set boundaries (small as they may be) to avoid maintainer burnout.
My point is that if you're an organization looking to use a tool like dae, the maintainers' behavior here is a huge red flag. Of course open-source projects can do basically whatever they want. But dae is really not a "personal project," its clearly designed for use by the broader community and the maintainer clearly wants lots of people to use it. If I am considering using any open-source software, I would want to understand the devs' decision-making behind denying good feature requests:
1) The best possible reason is work-life balance, "hey I'm not getting paid for this," etc etc. I am not demanding that dae's maintainers accept the change simply because it's a good idea.
2) An unpleasant but probably acceptable reason is obstinance, stubbornness, etc. Maybe you're wrong, the feature is a bad idea. But even if you're right, sometimes you have to accept the aesthetic/ideological quirks of the devs.
3) The worst possible reason for denying a feature request is pettiness or narcissism, which is exactly what dae is doing. Perhaps the user had legitimate reasons for not starring the repo (GitHub "learns from" your stars and will suggest related repos in discovery, which can be annoying). But the idea of labelling CI tests as a "wontfix" until you get a stupid GitHub star is just horrendous open-source management.
I'll star a repo when I want to add it to my "favourite" or "interesting" repos - they are all listed under "Your stars". Is there a better way of achieving the same?
I'm using a local gitweb instance for this purpose. I have a directory of favorite repos cloned using "git clone --mirror" and a cron job to sync them every 3 hours. gitweb provides a web interface for browsing them.
I like that it lets me open files without JavaScript enabled and search the code without logging in. I still use GitHub.com to read the issues on a couple repos though.
1) Good: This adds "just" a touch of friction to things. You can't just do a drive-by on the project like so many thanks to ill-advised "social good" corporate review policies (screw you, Google, for pioneering that). You have to at least star it which at least signifies some level of commitment, identity, and existence.
2) Bad: This causes an inflation war between those projects that do this organically and those that force people to star them. It squashes the signal in the idea of stars.
Github is going to have to remove identity from the stars if they want to stop this from descending into chaos.
I agree with this. If you use some software (and its author cares about internet points), you can at least give it that star. It's better than paying with money, and if you are requesting a feature it makes even more sense to pay with a single click of a mouse. Show some appreciation, people
No. I'm not going to break my own user pattern (I use stars as bookmarks, that's it. and I unstar pretty aggressively once I've done my business) to satisfy someone's ego. I'd much rather give a donation or bounty than go through that emotional manipulation. At least giving money is a business-neutral way to show demand for a feature (for a product I may or may not like).
Also, as a rebellious streak I am much less likely to star something that already has (proportionately) a bunch of stars.
Seems obnoxious without a doubt, and particularly egregious if reporter is bringing/offering a fix. But maybe I should try to be open-minded about this? Issues that provide even badly written bug reports are probably doing a service to the project itself. Feature requests OTOH might just be internet strangers requesting free labor on someone's generously-public yet resource-starved passion project. In the 2nd case, and without speculating on why the project owner would even care.. maybe fake internet points in lieu of other payment is the least people can do. That said though, obviously if everyone does this, it will erode the signal of what stars are supposed to mean. Hmm.
> if everyone does this, it will erode the signal of what stars are supposed to mean.
What signal? To me, starring a Github project means "I'm interested enough in this project to want to be able to find it again". That's a significantly lower bar than the poster had here, of "I've a new feature proposed for this project, and I'm even interested in implementing it myself if the maintainer agrees".
There's a loose correlation of stars with quality/popularity/ activity. All of those correlations should become stronger by having active users and bug reporters star the project.
Thats a false equivalence. Asking a repo maintainer to fix an issue or implement a new feature is requesting their voluntary work. This has nothing to do with silencing disagreement.
Readit News
Either way, feels sleazy.
[0] https://docs.github.com/en/site-policy/acceptable-use-polici...
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
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.
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.)
versus
gaining one (1) point on GitHub
Truly craven that this is coming from an automated bot. The extent to which social media likes have broken peoples' brains is something to behold.
I really don't understand the "seems fair" comments.
I (stupidly I see now) treat the stars as feature just for me, like a bookmark in my own browser. There for my use, not anyone else's.
Obviously that was silly since they are public and anything that is public is someone somewhere's currency, and anything that is currency will expose the lowest of the low human behavior.
And this IS automated. The automation is in the form of a policy rather than a scripting language, but it's still a mechanistic rule where a star is produced by application of an if-this-then-that, and by a transaction, purchased exactly like with money. By at least those TWO different means this is not an honest reflection of a users regard or admiration or expression of value.
Github surely would see that as devaluing stars and harming a feature of their site. Surely github does not want stars to become like amazon reviews.
1) The best possible reason is work-life balance, "hey I'm not getting paid for this," etc etc. I am not demanding that dae's maintainers accept the change simply because it's a good idea.
2) An unpleasant but probably acceptable reason is obstinance, stubbornness, etc. Maybe you're wrong, the feature is a bad idea. But even if you're right, sometimes you have to accept the aesthetic/ideological quirks of the devs.
3) The worst possible reason for denying a feature request is pettiness or narcissism, which is exactly what dae is doing. Perhaps the user had legitimate reasons for not starring the repo (GitHub "learns from" your stars and will suggest related repos in discovery, which can be annoying). But the idea of labelling CI tests as a "wontfix" until you get a stupid GitHub star is just horrendous open-source management.
I like that it lets me open files without JavaScript enabled and search the code without logging in. I still use GitHub.com to read the issues on a couple repos though.
Example of what gitweb looks like: https://sourceware.org/git/ - There's also cgit which is similar: https://git.kernel.org/
1) Good: This adds "just" a touch of friction to things. You can't just do a drive-by on the project like so many thanks to ill-advised "social good" corporate review policies (screw you, Google, for pioneering that). You have to at least star it which at least signifies some level of commitment, identity, and existence.
2) Bad: This causes an inflation war between those projects that do this organically and those that force people to star them. It squashes the signal in the idea of stars.
Github is going to have to remove identity from the stars if they want to stop this from descending into chaos.
They were still of use to me, and in cases did implement those features later on.
Also, as a rebellious streak I am much less likely to star something that already has (proportionately) a bunch of stars.
What signal? To me, starring a Github project means "I'm interested enough in this project to want to be able to find it again". That's a significantly lower bar than the poster had here, of "I've a new feature proposed for this project, and I'm even interested in implementing it myself if the maintainer agrees".
There's a loose correlation of stars with quality/popularity/ activity. All of those correlations should become stronger by having active users and bug reporters star the project.
Well if you're policy is to keep track of issues based on who stars the project, having a lot of stars means poor quality then.
I kind of understand their twisted logic but at the end of the day it just doesn't feel right.
There are plenty of projects who do not need this kind of policy to have a lot of stars.