3 ms·

Not sure about this one. I understand the need and the idea behind it is well-intentioned, but I can easily see denouncelists turn into a weapon against wrongth

by HiPhish 8mo ago

Not sure about this one. I understand the need and the idea behind it is well-intentioned, but I can easily see denouncelists turn into a weapon against wrongthinkers. Said something double-plus-ungood on Twitter? Denounced. Accepted contribution from someone on a prominent denouncelist? Denouced. Not that it was not possible to create such lists before, but it was all informal. The real problem are reputation-farmers. They open hundreds of low-effort PRs on GitHub in the hope that some of them get merged. This will increase the reputation of their accounts, which they hope will help them stand out when applying for a job. So the solution would be for GitHub to implement a system to punish bad PRs. Here is my idea: - The owner of a repo can close a PR either neutrally (e.g. an earnest but misguided effort was made), positively (a valuable contribution was made) or negatively (worthless slop) - Depending on how the PR was closed the reputation rises or drops - Reputation can only be raised or lowered when interacting with another repo The last point should prevent brigading, I have to make contact with someone before he can judge me, and he can only judge me once per interaction. People could still farm reputation by making lots of quality PRs, but that's actually a good thing. The only bad way I can see this being gamed is if a bunch of buddies get together and merge each other's garbage PRs, but people can already do that sort of thing. Maybe the reputation should not be a total sum, but per project? Anyway, the idea is for there to be some negative consequences for people opening junk PRs.

zozbot234 8mo ago
GitHub needs to implement eBay-like feedback for contributors. With not only reputation scores, but explanatory comments like "AAAAAAAAAAAAAA++++++++++++ VERY GOOD CONTRIBUTIONS AND EASY TO WORK WITH. WOULD DEFINITELY MERGE THEIR WORK AGAIN!"
- HiPhish 8mo ago
  I think merged PRs should be automatically upvoted (if it was bad, why did you merge it?) and closed unmerged PRs should not be able to get upvoted (if it was good, why did you not merge it?).
  - MarkusQ 8mo ago
    Intrinsically good, but in conflict with some larger, out of band concern that the contributor could have no way to know about? Upvote to take the sting out of rejection, along with a note along the lines of "Well done, and we would merge is it weren't for our commitment to support xxx systems which are not compatible with yyy. Perhaps refactor as a plugin?" Also, upvotes and merge decisions may well come from different people, who happen to disagree. This is in fact healthy sometimes.
- Loughla 8mo ago
  The ones I've never understood are: Prompt payment. Great buyer. I can't check out unless I pay. How is that feedback?
  - HiPhish 8mo ago
    I don't know how it is where where you live, but here there are two possibilities I can think of: - When I buy an item I still have to click a "check out" link to enter my address and actually pay for the item. I could take days after buying the item to click that link. - Some sellers might not accept PayPal, instead after I check out I get the sellers bank information and have to manually wire the money. I could take days after checking out to actually perform the money transfer.
  - jcattle 8mo ago
    On auctions, you do not have to provide a payment method to bid. So once you won an auction you still have to pay the agreed price. Only after the buyer paid, does the seller get the shipment address. Depending on the buyer this can take longer or shorter (or won't happen at all).
    - Loughla 8mo ago
      That actually makes a lot of sense. Thank you for explaining that. I legitimately didn't consider auctions.
  - layer8 8mo ago
    There are people who bid but then don’t pay if they win the auction. Or take weeks to pay after winning. That’s just a pain for the seller, because they have to spend time trying to get the winner to pay, or else have to put up the auction again (which used to cost some fee each time for the seller, I don’t know how it is now). The only penalty for non-paying winners is the negative feedback they receive.
- zbentley 8mo ago
  I know this is a joke, but pretending for a moment that it isn’t: this would immediately result in the rep system being gamed the same way it is on eBay: scam sellers can purchase feedback on cheap or self-shipping auctions and then pivot into defrauding people on high-dollar sales before being banned, rinse, and repeat.
  - jcattle 8mo ago
    Let's also see the differences: On github you can always see the interactions. On ebay, once a sale has been made, you have no idea what happens next. On Github you always have all the artifacts of where the reputation comes from.
pixl97 8mo ago
>The only bad way I can see this being gamed is if a bunch of buddies get together and merge each other's garbage PR Ya, I'm just wondering how this system avoids a 51% attack. Simply put there are a fixed number of human contributers, but effectively an infinite number of bot contributers.
pwdisswordfishs 8mo ago
> The real problem are reputation-farmers. They open hundreds of low-effort PRs on GitHub in the hope that some of them get merged. This will increase the reputation of their accounts, which they hope will help them stand out when applying for a job. So the solution would be for GitHub to implement a system to punish bad PRs. GitHub customers really are willing to do anything besides coming to terms with the reality confronting them: that it might be GitHub (and the GitHub community/userbase) that's the problem. To the point that they'll wax openly about the whole reason to stay with GitHub over modern alternatives is because of the community, and then turn around and implement and/or ally themselves with stuff like Vouch: A Contributor Management System explicitly designed to keep the unwashed masses away. Just set up a Bugzilla instance and a cgit frontend to a push-over-ssh server already, geez.
- stavros 8mo ago
  I mean, "everyone already has an account" is already a very good reason. That doesn't mean "I automatically accept contributions from everyone", it might be "I want to make the process of contribution as easy as possible for the people I want as contributors".
  - pwdisswordfishs 8mo ago
    Hatching a reputation-based scheme around a "Contributor Management System" and getting "the people you want as contributors" to go along with it is easier than getting them to fill in a 1/username 2/password 3/confirm-password form? Choosing to believe that is pure motivated reasoning.
    - stavros 8mo ago
      People aren't on Github just to implement reputation-based management, though.
      - pwdisswordfishs 8mo ago
        What does that observation have to do with the topic under the microscope?

by HiPhish 8mo ago

zozbot234 8mo ago

GitHub needs to implement eBay-like feedback for contributors. With not only reputation scores, but explanatory comments like "AAAAAAAAAAAAAA++++++++++++ VERY GOOD CONTRIBUTIONS AND EASY TO WORK WITH. WOULD DEFINITELY MERGE THEIR WORK AGAIN!"

HiPhish 8mo ago
I think merged PRs should be automatically upvoted (if it was bad, why did you merge it?) and closed unmerged PRs should not be able to get upvoted (if it was good, why did you not merge it?).
- MarkusQ 8mo ago
  Intrinsically good, but in conflict with some larger, out of band concern that the contributor could have no way to know about? Upvote to take the sting out of rejection, along with a note along the lines of "Well done, and we would merge is it weren't for our commitment to support xxx systems which are not compatible with yyy. Perhaps refactor as a plugin?" Also, upvotes and merge decisions may well come from different people, who happen to disagree. This is in fact healthy sometimes.
Loughla 8mo ago
The ones I've never understood are: Prompt payment. Great buyer. I can't check out unless I pay. How is that feedback?
- HiPhish 8mo ago
  I don't know how it is where where you live, but here there are two possibilities I can think of: - When I buy an item I still have to click a "check out" link to enter my address and actually pay for the item. I could take days after buying the item to click that link. - Some sellers might not accept PayPal, instead after I check out I get the sellers bank information and have to manually wire the money. I could take days after checking out to actually perform the money transfer.
- jcattle 8mo ago
  On auctions, you do not have to provide a payment method to bid. So once you won an auction you still have to pay the agreed price. Only after the buyer paid, does the seller get the shipment address. Depending on the buyer this can take longer or shorter (or won't happen at all).
  - Loughla 8mo ago
    That actually makes a lot of sense. Thank you for explaining that. I legitimately didn't consider auctions.
- layer8 8mo ago
  There are people who bid but then don’t pay if they win the auction. Or take weeks to pay after winning. That’s just a pain for the seller, because they have to spend time trying to get the winner to pay, or else have to put up the auction again (which used to cost some fee each time for the seller, I don’t know how it is now). The only penalty for non-paying winners is the negative feedback they receive.
zbentley 8mo ago
I know this is a joke, but pretending for a moment that it isn’t: this would immediately result in the rep system being gamed the same way it is on eBay: scam sellers can purchase feedback on cheap or self-shipping auctions and then pivot into defrauding people on high-dollar sales before being banned, rinse, and repeat.
- jcattle 8mo ago
  Let's also see the differences: On github you can always see the interactions. On ebay, once a sale has been made, you have no idea what happens next. On Github you always have all the artifacts of where the reputation comes from.

pixl97 8mo ago

>The only bad way I can see this being gamed is if a bunch of buddies get together and merge each other's garbage PR Ya, I'm just wondering how this system avoids a 51% attack. Simply put there are a fixed number of human contributers, but effectively an infinite number of bot contributers.

pwdisswordfishs 8mo ago

> The real problem are reputation-farmers. They open hundreds of low-effort PRs on GitHub in the hope that some of them get merged. This will increase the reputation of their accounts, which they hope will help them stand out when applying for a job. So the solution would be for GitHub to implement a system to punish bad PRs. GitHub customers really are willing to do anything besides coming to terms with the reality confronting them: that it might be GitHub (and the GitHub community/userbase) that's the problem. To the point that they'll wax openly about the whole reason to stay with GitHub over modern alternatives is because of the community, and then turn around and implement and/or ally themselves with stuff like Vouch: A Contributor Management System explicitly designed to keep the unwashed masses away. Just set up a Bugzilla instance and a cgit frontend to a push-over-ssh server already, geez.

stavros 8mo ago
I mean, "everyone already has an account" is already a very good reason. That doesn't mean "I automatically accept contributions from everyone", it might be "I want to make the process of contribution as easy as possible for the people I want as contributors".
- pwdisswordfishs 8mo ago
  Hatching a reputation-based scheme around a "Contributor Management System" and getting "the people you want as contributors" to go along with it is easier than getting them to fill in a 1/username 2/password 3/confirm-password form? Choosing to believe that is pure motivated reasoning.
  - stavros 8mo ago
    People aren't on Github just to implement reputation-based management, though.
    - pwdisswordfishs 8mo ago
      What does that observation have to do with the topic under the microscope?