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.

▲

pwdisswordfishs 3 hours ago | parent | next [-]

> 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 3 hours ago | parent [-]

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 2 hours ago | parent [-]

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 2 hours ago | parent [-]

People aren't on Github just to implement reputation-based management, though.

▲

pwdisswordfishs 2 hours ago | parent [-]

What does that observation have to do with the topic under the microscope?

	▲	stavros an hour ago \| parent [-]
		> 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. The community might be a problem, but that doesn't mean it's a big enough problem to move off completely. Whitelisting a few people might be a good enough solution.

▲

zozbot234 5 hours ago | parent | prev | next [-]

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!"

▲

zbentley 4 hours ago | parent | next [-]

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.

▲

Loughla 5 hours ago | parent | prev | next [-]

The ones I've never understood are: Prompt payment. Great buyer.

I can't check out unless I pay. How is that feedback?

	▲	HiPhish an hour ago \| parent [-]
		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.

▲

HiPhish 5 hours ago | parent | prev [-]

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 5 hours ago \| parent [-]
		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.

▲

pixl97 4 hours ago | parent | prev [-]

>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.