Live data from Hacker News

We stopped AI bot spam in our GitHub repo using Git's –author flag

archestra.ai

241–250 of 254 posts

Re: We stopped AI bot spam in our GitHub repo using Git's –author flag

#241

[flagged]

What is the benefit of deleting a PR over just closing it? It seems like closing has the benefit of signaling what kinds of PRs aren't acceptable, which deleting would lose.

In the future, when you're looking at past PRs, you'll end up with a list of closed PRs that look legitimate from their titles. You'll waste time opening each one to figure out why it was closed.

This is particularly annoying because PRs also show up in the issue and in the issue list as "this issue has 3 PRs that will close it", when it's all. just. spam.

Re: We stopped AI bot spam in our GitHub repo using Git's –author flag

#242
post #177

Earlier quoted context omitted.

Closing a PR or issue still makes it discoverable in PR/issue search results, as opposed to deleting an issue.

This. But OP wanted special requirements to open a PR. I.e. if those requirements are not met the PR is never visible to all and so admins can reject spam PRs without giving them a platform.

We occasionally get traditional SPAM PRs pointing to their product. In that case it is very useful to clear out title, PR body and reset the commits as well, so none of that appears on the repo.

This is time consuming.

Unfortunately the PR and the PR author will forever be listed there and linking to their product anyway.

Re: We stopped AI bot spam in our GitHub repo using Git's –author flag

#243
post #233

> It's especially sensitive for a VC-backed startup that is measured thoroughly by GitHub activity, but we have to pull the trigger: This sentence also illustrates the absurdity of this investment model. It imposes a trade-off between building good software, and complying with the investor's metrics. They probably call such metrics evidence-based, but this example shows that they arbitrarily capture some numbers to o…

It's called a signaling game. Of course it's dumb, but how else do you measure traction besides revenue? Building good software is a small part of running a business.

I don't know, and I think there is no easy answer. The point is: the investors don't know how to measure traction either, so they just measure GitHub activity instead, even at the very moment in which it becomes obvious that it does not capture actual traction. The absurdity lies in the statement that the developers still need to gain actual traction while putting additional effort into gaming that metric to satisfy their investors.

Re: We stopped AI bot spam in our GitHub repo using Git's –author flag

#245
post #47

I'm not sure why gh hasn't already implemented stricter measures / filters / tools for PRs. It would cut down on spam and also help save their servers that can't handle the increased AI load!

They want the number of PRs to be as high as possible because that’s what investors care about. Why would they do something that decreases it?

Re: We stopped AI bot spam in our GitHub repo using Git's –author flag

#246
post #61

This is great example of the toxic effect money has on open source. Reward people with respect and recognition instead. Weird anonymous accounts no one's ever heard of will leave, because someone (or something) who's concealing their identity has nothing to gain from recognition. Honestly GitHub should have a real names policy. Because if you're not Satoshi Nakamoto then there's only three reasons I can think of to b…

Linux kernel contribution policy required sending patches under real name, but that policy have been lifted about 2 years ago. Now they allow pseudonym contributions.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

https://github.com/cncf/foundation/blob/659fd32c86dc/dco-gui...

Re: We stopped AI bot spam in our GitHub repo using Git's –author flag

#247
post #91

Earlier quoted context omitted.

This is an overly negative response to a genuine solution. There are a million reasons you shouldn't do X or Y. More than likely GitHub would have to maintain their own internal wallet solution for this, which is a big engineering lift. But we're all just having a discussion.

> to a genuine solution Except it isn't. It is a lazy solution and impractical one > More than likely GitHub would have to maintain their own internal wallet solution Great, so you even found one of the main issues, which pushes off the problem to a third party which makes it an impossible solution for anyone but GitHub (still a problematic "solution" though) > This is an overly negative response Yet it isn't because…

> There's two types of lazy, and this is the kind that creates more work, not less

Well put. Thanks for taking the time to call this out. Your two comments here are balm for the mental anguish and annoyance I went through reading the so-full-of-misplaced-confidence original comment.

Re: We stopped AI bot spam in our GitHub repo using Git's –author flag

#248

[flagged]

We’re currently working on a feature that lets admins archive PRs. The goal is to give maintainers more control over how they manage contributions in their repositories. Archived PRs would be visible to admins only, so maintainers still have access to contributor history for auditing purposes and to meet any organizational or compliance requirements. Would this be helpful for you?

Boot spammers off your platform, stop them from coming back. Its a moderation issue, the more companies want to pretend like its not their problem - the worse it gets.

Re: We stopped AI bot spam in our GitHub repo using Git's –author flag

#250
post #61

This is great example of the toxic effect money has on open source. Reward people with respect and recognition instead. Weird anonymous accounts no one's ever heard of will leave, because someone (or something) who's concealing their identity has nothing to gain from recognition. Honestly GitHub should have a real names policy. Because if you're not Satoshi Nakamoto then there's only three reasons I can think of to b…

Linux kernel contribution policy required sending patches under real name, but that policy have been lifted about 2 years ago. Now they allow pseudonym contributions. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... https://github.com/cncf/foundation/blob/659fd32c86dc/dco-gui...

So my mission critical infrastructure depends on a group whose bar for entry is having a proton mail account.

I bet they claimed to be protecting trans people to get that policy changed too.

Post reply on HN