Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

archestra.ai

Post reply on HN
Print view View original

231–240 of 254 posts

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

#231

Post by marcus_holmes »

watwut wrote: post #224
marcus_holmes wrote: post #198

Earlier quoted context omitted.

No, this is a result of unintended consequences. We made "Github contributions" a metric for people applying for dev jobs. So, of course, because devs are the kind of people we are, they started working out how to game that metric. Some folks decided to start paying bounties on bug fixes, features, etc. Those bounties are fairly trivial by western standards, but are significant for developing countries. This creates…

This feels like an alternative history. OS contributions were never all that important metric and overwhelming majority of developers have literally none. And it is not like AI spam would be limited or even primary targetted at bounties.

There's a whole thing about advising new folks in the industry to contribute to OS projects on github as proof that they're actually really keen developers.

This [0] is an example, there are many more.

The whole idea that we have to have a "portfolio" of work.

[0] https://talentslab.io/7-strategies-for-a-junior-developer-to...

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

#232

Post by duskdozer »

ZoneZealot wrote: post #175
thih9 wrote: post #55

> It's not a contract job— it's our optional way of saying thank you to the community. The writing style in their onboarding doc has common AI tells (in the quote: em dashes, “it’s not A, it’s B” sentence). I can understand that, perhaps they want to fight fire with fire or don’t have time as they already say. Still, it all feels like inadequate half measures to me.

The entire post is clearly LLM generated. I get that a person clearly put together some thoughts, but prompting an LLM to 'turn this into a blog post' is the kind of low effort content I thought was not appropriate for HN. At least bringing up the underlying method (restrict to contributors) has spawned the discussion about how that's probably a bad idea on the security side.

Well it is a .ai domain and they run some kind of AI product (unclear what exactly) so I guess they just don't see an issue with that sort of thing. I don't know if people are happily reading stuff like this or if they just get the "AI summary"

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

#233

Post by bloppe »

carschno wrote: post #213

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

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

#234

Post by bloppe »

darccio wrote: post #226
karussell wrote: post #190

Earlier quoted context omitted.

Not OP but requested this feature since years. Your suggestion would help a bit but I would prefer the opposite: before someone can 'pollute' my pull request space and draw attention from subscribers I would prefer an acceptance step (just like a moderator on a forum) instead of having to archive the PRs. This is especially important as (AI) spam increases and just because I am away for a few days or weeks I don't wa…

A PR staging area. This would be a good step forward.

That kinda sounds like draft PRs. You can make all PRs drafts by default. I guess it would be cool to have a setting where only maintainers can change it to ready-for-review.

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

#235

Post by expedition32 »

rvnx wrote: post #112
smaudet wrote: post #104

Earlier quoted context omitted.

Which is not chrome and still has ads...(Ironically). The issue here is the core model is broken (misaligned incentives). That's not something you are going to fix with a github "downstream". A token system could help but it's easy to imagine ways that could be gamed, if not implemented well.

Ads are the main business model of browsers. If search ads are blocked on search engines, then there is no revenue for the browser. It's that simple (on top of that Brave has other revenues, but the majority is search ads). So it's a game of hoping that the majority won't change the default. This is the main reason Brave does not block search ads specifically by default, but still block the other ads. Blocking the ot…

Ads are the main business of the internet.

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

#236

Post by iiTzSYREX »

I think it's a great approach. I checked the repo and saw that each contributor onboarding triggers the full CI pipeline, which is visible from the CI logs, including a Docker image build, GCP authentication, and a full Helm deploy. Aren't you guys wasting GCP compute and other things?

I am no expert in this, it's just something I noticed.

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

#237

Post by halapro »

tommica wrote: post #228
halapro wrote: post #126

[flagged]

I'd imagine this is not a simple problem to solve, and legacy code is probably causing a massive headache too

They do have ways to limit interactions already, but they work on a whitelist level rather than dynamically based on user "score" (account age, contribution history, etc). If a user gets their comments deleted and blocked from organizations, GitHub should already know it's a spammer.

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

#238

Post by halapro »

moraesc wrote: post #173
halapro wrote: post #126

[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?

This doesn't help with PR spam if that junk still shows up in regular "is:pr" searches. I don’t think unrequested unmerged AI PR spam is useful for compliance, just like deleted comments and issues aren't.

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

#239

Post by halapro »

bloppe wrote: post #234
darccio wrote: post #226

Earlier quoted context omitted.

A PR staging area. This would be a good step forward.

That kinda sounds like draft PRs. You can make all PRs drafts by default. I guess it would be cool to have a setting where only maintainers can change it to ready-for-review.

If the PR exists on my repo, it's already too late.

Either you let me block 6-month old accounts from opening PRs, or you let me delete them.

PRs, draft or not, show up in searches and spammers can continue opening new ones as well as leaving comments on them.

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

#240

Post by halapro »

hpjev wrote: post #222
moraesc wrote: post #173

Earlier quoted context omitted.

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?

I can only speak for myself, being a maintainer of a project in the crypto space. We are getting spammed with AI slop and also scam comments (though this lessened for some reason). My usual experience is this: 1. We open an issue that needs to be fixed 2. slop bots create multiple slop PRs 3. slop bots spam comments on the issues, pointing to their slop PRs The only general methods for preventing this are are restric…

This has two good points:

- add "Pull Request requests" that operate like Friend requests. You can't open PRs until you've been whitelisted (temporarily or not) or are proven to be a good OSS citizen (TBD)

- add a "Burn it with fire" action in new PRs that deletes all comments and PRs opened by the user across the repo, as well as blocking the user.

Organizations already sort of have this, but the action does not delete/close PRs.

Post reply on HN