21 ms·

No star, No fix

186 points by rustdesk 3y ago

theamk 3y ago
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" ? Either way, feels sleazy. [0] https://docs.github.com/en/site-policy/acceptable-use-policies/github-acceptable-use-policies https://docs.github.com/en/site-policy/acceptable-use-polici...
- andersonmvd 3y ago
  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 [0] https://github.com/google/eddystone/issues/258 https://github.com/google/eddystone/issues/258
  - sainez 3y ago
    It is at least partially automated. The issue was closed by a bot which requires a star to re-open.
    - junon 3y ago
      That's clearly not the spirit of the T&C's of GitHub.
      - anilakar 3y ago
        Seeing that both the devs and target audience are in mainland China, they're used to rules and regulations being more like suggestions anyway.
        miki123211 3y ago
        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.
  - forgotpwd16 3y ago
    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.
  - oliwarner 3y ago
    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.
    - franciscop 3y ago
      > Bug reporting helps projects get better 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.
      - skywal_l 3y ago
        > 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.
        actionfromafar 3y ago
        Maybe not, but at least they got a star out of it. Github sets up social network gamification incentives, wins social network gamification prizes…
        johnnyanmac 3y ago
        Well yes. And like any good game you should report abuse of its features.
  - soerxpso 3y ago
    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.
  - theamk 3y ago
    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.)
xeckr 3y ago
>understood iconic
nicklecompte 3y ago
Gaining a permanent reputation for petty authoritarianism, even with contributors who clearly want to help 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.
- tomalbrc 3y ago
  understood
- zokier 3y ago
  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.
  - nicklecompte 3y ago
    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.
- Brian_K_White 3y ago
photonthug 3y ago
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.
- dmurray 3y ago
  > 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.
  - skywal_l 3y ago
    > There's a loose correlation of stars with quality/popularity/ activity 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.
aluminum96 3y ago
The mean goose avatar for the bot is perfect.
- ceautery 3y ago
  That's stolen from "Untitled Goose Game".
_8j50 3y ago
Why the negative sentiment against this? It doesn't cost people anything to star a project. Whether it is a PR or not, the maintainer still had to review and maintain the code and that is time they will spend. The more stars a project gets, the more support it gets. It's not like you pay for stars or it is burdensome to click on the star button.
- eviks 3y ago
  How do toy magically get more support if all projects simply demand more stars and get them?
  - _8j50 3y ago
    If you like it starting it makes sense, if you don't why open issues and do pr's?
    - eviks 3y ago
      There are trivial responses to your question, but you didn't address the issue I raised
      - _8j50 3y ago
        I thought it was obvious. Not all projects get stars, the ones people use and like the most get more support in form of contribution which could be issues and pr's or other types of support. For people who don't care abour stars it means nothing, for those who do it means everything.
        eviks 3y ago
        It's not obvious since it's false, you've just ignored the core point "if all projects simply demand more stars and get them" that pointed to the flaw in your logic. Also no, people are not binary state machines with either "means nothing" or "means everything" states
chupapimunyenyo 3y ago
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
- tetromino_ 3y ago
  It seems ludicrous to have to star a project for lacking a feature you need. What's next, starring projects for having glaring security problems?
  - chupapimunyenyo 3y ago
    The person that asked for the feature clearly uses the project and this is usually the case. USERS of a project ask for features
    - moron4hire 3y ago
      The person in the linked GitHub repo is not asking the maintainers to develop the feature. They are asking if the maintainers would like the issue author to develop the feature. That's what is particularly disgusting to me about this star-begging-bot.
      - actionfromafar 3y ago
        They are asking the maintainers to take the time to evaluate and possibly shepherd a patch into the mainline. It may or may not work out in the end. Everything has a cost, not the least, opportunity cost. “Libre” is not “gratis” and all that.
  - MrDresden 3y ago
    I have starred plenty of projects that lack features that I would have liked or needed them to have. They were still of use to me, and in cases did implement those features later on.
kazinator 3y ago
Reminds me of how how people give trivial stuff away for "free" in online marketplaces, but ask to be paid with a good review before handing it over. Do that a few hundred times and whoa, you're an amazingly rated seller!
- johnnyanmac 3y ago
  Yeah, that's why I hate this model to begin with (and basically never leave reviews for software). If you have to ask/bribe me for a review, you ruined the point of what a review it. It is to let other prospector buyers know my genuine experience with the product or seller. 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.
bsder 3y ago
I'm of two minds on this: 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.
- zokier 3y ago
  You think stars before had some widely agreed upon common idea that was not chaotic?
junon 3y ago
This is ridiculous. Not every issue means someone likes or even uses the codebase. 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.
- ZoomZoomZoom 3y ago
  Don't forget, nobody prevents the user from opening an issue. If it's critical and the maintainers care, they'll work on it with or without the user's star.
  - junon 3y ago
    I think you missed the part where the issue was closed by the bot for the user not having starred the repo, in which case - especially on high-traffic repos - the likelihood of actually seeing it is reduced.
    - ZoomZoomZoom 3y ago
      Maintainers not auditing issues closed by their bots are irresponsible, but this problem is not related to the nature of the close-triggering condition.
- zokier 3y ago
  You are assuming such drive-by issues are actually valuable; to me it is not 100% self-evident, especially when most projects do not have shortage of issues anyways.
  - arp242 3y ago
    Some are, some are not. Assuming all are valuable would indeed be incorrect, but so would assuming all are worthless. 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.
dc3k 3y ago
I don’t think I have ever starred anything on Github. I think in this sort of situation I would add the star and remove it once the fix is added.
- baal80spam 3y ago
  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?
  - nishs 3y ago
    is lack of privacy your issue with the "your stars" page? consider a bookmarks manager.
    - Narushia 3y ago
      You can make the profile private and it’ll hide the stars.
      - actionfromafar 3y ago
        Can't hide the stars from Github itself though. Keeping as much preference data away from social networks as possible is not an unreasonable stance, IMHO.
        Hamuko 3y ago
        You also can't hide the fact that you're browsed or even cloned the repository from GitHub, since it's on their servers.
        actionfromafar 3y ago
        Perfect is the enemy of good. Much harder for some website to correlate random dowmloads to a specific identity.
_lvbh 3y ago
What are stars even worth? Certainly not the number of possible contributors this chases away (I see issue reporters as contributors as well since they’re spending effort finding/debugging what you would have to do at some point anyways) All this for a measly 1500 stars
- yeeeeeee 3y ago
  Maybe to put the repository on a resume. Github also gives out free Copilot licenses to active contributors of opens-source/free-software projects but they don't say specifically what the requirements are. Maybe if you own or contribute to a repository with many stars you're eligible for that.
- randyrand 3y ago
  It helps make the repo most popular - more bug reports - more community documentation - more user testing - etc
avgcorrection 3y ago
No clout, no work seems reasonable if on the nose. At least you don’t have to subscribe to a newsletter.
- avgcorrection 3y ago
  Imagine if I could demand that only people who have upvoted my comment could reply to it? I would get much less disagreeable replies.
  - rafaelrc 3y ago
    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.
    - avgcorrection 3y ago
      Huh? That was just a non-funny aside.
MrDresden 3y ago
The reactionary way to respond to this seems to be to think this is somehow authoritarian, internet point gathering or just petty. 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.
deleted 3y ago
[deleted]
fortyseven 3y ago
Not sure which is more gross: having a bot farm for imaginary internet points, or the people defending the practice.
Brian_K_White 3y ago
This is Trump demanding that everyone at a meeting say something good about him. 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!
juxtapose 3y ago
This is unethical if (1) the condition was not made clear before the issue is written, and (2) the user cannot delete their report before it is published. (It is not in the current issue template, and I don't know if it was there.) 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.

186 points by rustdesk 3y ago

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" ? Either way, feels sleazy. [0] https://docs.github.com/en/site-policy/acceptable-use-policies/github-acceptable-use-policies https://docs.github.com/en/site-policy/acceptable-use-polici...

andersonmvd 3y ago
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 [0] https://github.com/google/eddystone/issues/258 https://github.com/google/eddystone/issues/258
- sainez 3y ago
  It is at least partially automated. The issue was closed by a bot which requires a star to re-open.
  - junon 3y ago
    That's clearly not the spirit of the T&C's of GitHub.
    - anilakar 3y ago
      Seeing that both the devs and target audience are in mainland China, they're used to rules and regulations being more like suggestions anyway.
      - miki123211 3y ago
        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.
- forgotpwd16 3y ago
  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.
- oliwarner 3y ago
  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.
  - franciscop 3y ago
    > Bug reporting helps projects get better 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.
    - skywal_l 3y ago
      > 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.
      - actionfromafar 3y ago
        Maybe not, but at least they got a star out of it. Github sets up social network gamification incentives, wins social network gamification prizes…
        johnnyanmac 3y ago
        Well yes. And like any good game you should report abuse of its features.
- soerxpso 3y ago
  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.
- theamk 3y ago
  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.)

xeckr 3y ago

>understood iconic

nicklecompte 3y ago

Gaining a permanent reputation for petty authoritarianism, even with contributors who clearly want to help 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.

tomalbrc 3y ago
understood
zokier 3y ago
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.
- nicklecompte 3y ago
  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.
Brian_K_White 3y ago

photonthug 3y ago

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.

dmurray 3y ago
> 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.
- skywal_l 3y ago
  > There's a loose correlation of stars with quality/popularity/ activity 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.

aluminum96 3y ago

The mean goose avatar for the bot is perfect.

ceautery 3y ago
That's stolen from "Untitled Goose Game".

_8j50 3y ago

Why the negative sentiment against this? It doesn't cost people anything to star a project. Whether it is a PR or not, the maintainer still had to review and maintain the code and that is time they will spend. The more stars a project gets, the more support it gets. It's not like you pay for stars or it is burdensome to click on the star button.

eviks 3y ago
How do toy magically get more support if all projects simply demand more stars and get them?
- _8j50 3y ago
  If you like it starting it makes sense, if you don't why open issues and do pr's?
  - eviks 3y ago
    There are trivial responses to your question, but you didn't address the issue I raised
    - _8j50 3y ago
      I thought it was obvious. Not all projects get stars, the ones people use and like the most get more support in form of contribution which could be issues and pr's or other types of support. For people who don't care abour stars it means nothing, for those who do it means everything.
      - eviks 3y ago
        It's not obvious since it's false, you've just ignored the core point "if all projects simply demand more stars and get them" that pointed to the flaw in your logic. Also no, people are not binary state machines with either "means nothing" or "means everything" states

chupapimunyenyo 3y ago

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

tetromino_ 3y ago
It seems ludicrous to have to star a project for lacking a feature you need. What's next, starring projects for having glaring security problems?
- chupapimunyenyo 3y ago
  The person that asked for the feature clearly uses the project and this is usually the case. USERS of a project ask for features
  - moron4hire 3y ago
    The person in the linked GitHub repo is not asking the maintainers to develop the feature. They are asking if the maintainers would like the issue author to develop the feature. That's what is particularly disgusting to me about this star-begging-bot.
    - actionfromafar 3y ago
      They are asking the maintainers to take the time to evaluate and possibly shepherd a patch into the mainline. It may or may not work out in the end. Everything has a cost, not the least, opportunity cost. “Libre” is not “gratis” and all that.
- MrDresden 3y ago
  I have starred plenty of projects that lack features that I would have liked or needed them to have. They were still of use to me, and in cases did implement those features later on.

kazinator 3y ago

Reminds me of how how people give trivial stuff away for "free" in online marketplaces, but ask to be paid with a good review before handing it over. Do that a few hundred times and whoa, you're an amazingly rated seller!

johnnyanmac 3y ago
Yeah, that's why I hate this model to begin with (and basically never leave reviews for software). If you have to ask/bribe me for a review, you ruined the point of what a review it. It is to let other prospector buyers know my genuine experience with the product or seller. 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.

bsder 3y ago

I'm of two minds on this: 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.

zokier 3y ago
You think stars before had some widely agreed upon common idea that was not chaotic?

junon 3y ago

This is ridiculous. Not every issue means someone likes or even uses the codebase. 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.

ZoomZoomZoom 3y ago
Don't forget, nobody prevents the user from opening an issue. If it's critical and the maintainers care, they'll work on it with or without the user's star.
- junon 3y ago
  I think you missed the part where the issue was closed by the bot for the user not having starred the repo, in which case - especially on high-traffic repos - the likelihood of actually seeing it is reduced.
  - ZoomZoomZoom 3y ago
    Maintainers not auditing issues closed by their bots are irresponsible, but this problem is not related to the nature of the close-triggering condition.
zokier 3y ago
You are assuming such drive-by issues are actually valuable; to me it is not 100% self-evident, especially when most projects do not have shortage of issues anyways.
- arp242 3y ago
  Some are, some are not. Assuming all are valuable would indeed be incorrect, but so would assuming all are worthless. 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.

dc3k 3y ago

I don’t think I have ever starred anything on Github. I think in this sort of situation I would add the star and remove it once the fix is added.

baal80spam 3y ago
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?
- nishs 3y ago
  is lack of privacy your issue with the "your stars" page? consider a bookmarks manager.
  - Narushia 3y ago
    You can make the profile private and it’ll hide the stars.
    - actionfromafar 3y ago
      Can't hide the stars from Github itself though. Keeping as much preference data away from social networks as possible is not an unreasonable stance, IMHO.
      - Hamuko 3y ago
        You also can't hide the fact that you're browsed or even cloned the repository from GitHub, since it's on their servers.
        actionfromafar 3y ago
        Perfect is the enemy of good. Much harder for some website to correlate random dowmloads to a specific identity.

_lvbh 3y ago

What are stars even worth? Certainly not the number of possible contributors this chases away (I see issue reporters as contributors as well since they’re spending effort finding/debugging what you would have to do at some point anyways) All this for a measly 1500 stars

yeeeeeee 3y ago
Maybe to put the repository on a resume. Github also gives out free Copilot licenses to active contributors of opens-source/free-software projects but they don't say specifically what the requirements are. Maybe if you own or contribute to a repository with many stars you're eligible for that.
randyrand 3y ago
It helps make the repo most popular - more bug reports - more community documentation - more user testing - etc

avgcorrection 3y ago

No clout, no work seems reasonable if on the nose. At least you don’t have to subscribe to a newsletter.

avgcorrection 3y ago
Imagine if I could demand that only people who have upvoted my comment could reply to it? I would get much less disagreeable replies.
- rafaelrc 3y ago
  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.
  - avgcorrection 3y ago
    Huh? That was just a non-funny aside.

MrDresden 3y ago

The reactionary way to respond to this seems to be to think this is somehow authoritarian, internet point gathering or just petty. 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.

deleted 3y ago

[deleted]

fortyseven 3y ago

Not sure which is more gross: having a bot farm for imaginary internet points, or the people defending the practice.

Brian_K_White 3y ago

This is Trump demanding that everyone at a meeting say something good about him. 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!

juxtapose 3y ago

This is unethical if (1) the condition was not made clear before the issue is written, and (2) the user cannot delete their report before it is published. (It is not in the current issue template, and I don't know if it was there.) 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.