No star, No fix(github.com) |
No star, No fix(github.com) |
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
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 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.
1. The issue writer will invest time and efforts, and publish their findings. Nobody's time is free: the maintainer's time is precious, and so is a user's.
2. Now, _after_ the issue is published, the maintainer additionally asks for a certain condition (give money or a star) to be satisfied.
What if the issue writer does not want to give that thing? The maintainer is now in an unfair position: they can still read the published issue, improve their software, but is not obliged to give any feedback or even credit the reporter.
It would be fairer if the condition was clearly conveyed to the reporter before they write any words. The system should simply not allow these issues written by the dissents to be created in the first place, and in that case the funny duck would also not appear before our eyes.
All this for a measly 1500 stars
- more bug reports
- more community documentation
- more user testing
- etc
I don't mind being prompted for a review after the fact (because sure, I will forget otherwise), but it should be a prompt, not a beg.
A star is me saying "I admire this".
This is saying "hey you, admire me."
Super gross. How is anyone here trying to say that's reasonable?
And aside from being low, forget that, it's also stupid because it hurts your own self. Some users do submit feature requests in a demanding entitled manner, but most don't and even those that do are all still useful information about what the users want.
This user is only submitting an idea for consideration, and offering to do the work themselves if the idea is agreed with.
The devs* response to this is utterly bizarre in that context. "I won't hear your idea unless you like me." ??? The user is trying to GIVE them something!
Not all gifts are desirable of course but the value or fitness of the pr was never even considered in this case. They are refusing to even look in the bag to see if it's a turd or a gold brick unless the user claims to like them.
* devs bot, aka, which would seem to pretty squarely hit the acceptable use terms that specifically covers stars and automation and authentic user interactions. Not only is the devs policy a form of automation in that it's a plain mechanistic rule no different from a line of code, and is also a transaction like buying amazon reviews, on top of that it's literally a bot implementing the policy!
Automated scanners, fuzzers, security researchers, and people who found an issue via a dependent codebase, are all examples where an issue might be filed but the person otherwise has no interest.
What a nonsense thing to have. It's not harmless, especially for large projects. It'll discourage and even runs the risk of artificially covering up potential security issues.
In this case it's a "hey I want to make a patch, would you accept it?" type of question, and not really a bug report or feature request as such. I'd say that's valuable.
What some might not realize is the sheer volume of requests that maintainers of popular open source software projects have competing for their attention on a daily basis (I do not speak from experience but from reading/listening to reports from those that do).
Adding a bit of friction to any of those attention grabbing things, like here through the use of an bot, is a good way of reducing that noise at least somewhat. It isn't a perfect system, but it is the one this maintainer choose to use.
iconic
Filing an issue is not equivalent or a reasonable stand-in for interest and DEFINITELY not for regard or admiration.
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.
It actually makes the star count represent the interest in project. After all no one would be making bug report if they didn't have a reason. Probably because they have problem or want to use project.
If GH had levels of stars it might have be been better.
Can't projects say they'll only support people who really like the project or are people thinking OSS comes with entitlements for unpaying users.
> It's not like you pay for stars or it is burdensome to click on the star button.
Imagine being allowed to comment here only after [starring] something. It's not like you pay for [stars] or it is burdensome to click on the [star] button.
There are certainly projects for which I've opened issues that I wouldn't star, because I use stars as a way to get project updates on my github feed.
> No. Users should röstning for a story because they personally find it intellectually interesting, not because someone has content to promote. We penalize or ban submissions, accounts, and sites that break this rule, so please don't.
500 karma requirement is for downvoting, an anti-abuse measure, site-wide, not restricted by any other means. You don't need to upvote the submission to be able to vote on the comments on that submission.
Upvotes are available from the start.
So no, that's far off.
This behaviour is a clear as day extortion scheme yet you are aggressively defend it, which begs the question - why? Do you profit from similar schemes?
Yeah, right. And a star is anti-troll measure because they have to spend time reviewing the code for security issues or just validity, it's a minor reward for someone's time.
> So no, that's far off
I disagree, forced participation to be allowed to do something in both cases, except HN isn't reviewing my upvote unlike PRs.
> This behaviour is a clear as day extortion scheme yet you are aggressively defend it, which begs the question - why? Do you profit from similar schemes?
You are so entitled and being mean! What could one possible gain from a f*cking star? Even if they can gain from it so what? What do you lose?
What a mean attitude! Someone gains, you lose nothing and that is extortion in your entitled mind. Stop using open source software if you don't understand that you're not entitled to support you don't pay for and not every open source author will have the same rules and values as your those in your familiar bubble.
“Libre” is not “gratis” and all that.
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.
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.
Github sets up social network gamification incentives, wins social network gamification prizes…
i barely ever star any project. stars are public and so i will only star the most important projects that i want to recommend to others.
but i do occasionally make reports to projects that i don't actively use or don't want to recommend. if a project doesn't want my report without a star, then well, good luck to them.
> I don’t think I have ever starred anything on Github. (...)
- it's a dependency downstream and it's breaking my actual project.
- I'm in evaluation/research phase for multiple repos and am not committed to that specific tool. Actions like this actively make me NOT want to star such behavior, nor even use the tool if I can help it
- because I don't fundamentally use stars as a popularity stick and don't care. I'd rather you prompt me to post a bounty or donation instead. Yes, that's how much I hate that system; I will pay money to not be involved in it.
>Can't projects say they'll only support people who really like the project or are people thinking OSS comes with entitlements for unpaying users.
if you ignore the meta-gaming reasons this tactic exists, sure. I'd rather just pay the project directly instead be a part of a statitic that says "we got X stars on our repo please fund us" VC pitches.
You depend on it but so much as clicking in a star button is burdensome? Come on!
> I'm in evaluation/research phase for multiple repos and am not committed to that specific tool. Actions like this actively make me NOT want to star such behavior, nor even use the tool if I can help it
Then the author's don't want you to use their project, so fork it or move on.
> because I don't fundamentally use stars as a popularity stick and don't care. I'd rather you prompt me to post a bounty or donation instead. Yes, that's how much I hate that system; I will pay money to not be involved in it.
This isn't about you, it's a button the author cares about, so support them with it for their sake, if they want money they will ask for it.
> I'd rather just pay the project directly instead be a part of a statitic that says "we got X stars on our repo please fund us" VC pitches.
You are not part of any of thay, you are just supporting someone making their hard work free and open source in the way they want to be supported. This boils down to how you wish to support them and how you wish the system worked without a single consideration into their right to not support you for any reason at all. The software is already FOSS, you downvote their post and anything defending them because what? Being free and open isn't enough, you also deserve free labour and in your own terms?
I don't. Something I use depends on something depends on something... Depends on it, and I might not even agree with the dependency. I'm not rewarding something because of someone else's decision to use it.
>Then the author's don't want you to use their project, so fork it or move on.
At that point yes, I move on.
>This isn't about you.
Someone requests an action of me and people are confused by my response. So yes, it is about me. I can and do just say "no" and move on, but if people want me to clarify I will.
>You are not part of any of tha
Well they just made me a part of it. Congrats.
>The software is already FOSS, you downvote their post and anything defending them because what?
A lack of a star is not a downvote. And I'm very glad you can't downvote a repo. What a mess that would be. Why are you taking my inaction so personally? Who or what am I downcotijf to begin with?
I seel at this point you're arguing with a very different person than me.
That's your problem, this project is not responsible for your dependency on it with or without your choice!
> Someone requests an action of me and people are confused by my response. So yes, it is about me. I can and do just say "no" and move on, but if people want me to clarify I will.
Ok, so long as we agree it is their right to require arbitrary things as is yours to ditch them.
> Well they just made me a part of it
In the same way every human is a part of it? I don't follow.
> A lack of a star is not a downvote. And I'm very glad you can't downvote a repo.
No kidding. HN'ers are downvoting on the issue if you care to click on the link of the post and see.
I don't care about your inaction, I care about the negative entitled jerk sentiment on this thread!
I did not claim human beings are binary state machines. If you refuse to interpret my statements in good faith and in context then you don't want a discussion, you just want to feel right.
You attempted to justify the devs policy with demanding users, which is ridiculous on multiple fronts.
I thought that the question "Why?" asked about this particular fragment of GP's comment:
> I don’t think I have ever starred anything on Github. (...)
Not to the particular situation of fixes for likes. Therefore the answer:
> because I don't give out fake likes.
was thought to be an answer to question: "Why haven't you ever starred anything on Github?". With this in mind I just wanted to say that likes do not have to be fake. You can like what you like. It may be a bit off the general topic of fixes for likes, but not off the more general topic of Github likes.
In this particular case I don't know what I would do. Probably if I really needed it I would just comply. If I already would have liked it or was close to it I would probably also just do it. In other cases when I would have thought about this as a courtesy I would drop it.
I have a bunch of repositories liked. I use it as a bookmark and a signal of interest for maintainers. As much as one would want to claim Github stars are not meaningless Internet points. A search engine will promote more starred repositories more, more people in general will think about using the thing. It is not a perfect measure of course, but it is not meaningless signal. It may often not mean much, but most of the time it is more meaningful than not. For my particular interests I often seek out repositories that have not the most stars, but also not the least.
Hence my answer, I feel giving a star becsuse I was prompted to in order to do something unrelated is fake.