GitHub Community
Allow us to block Copilot-generated issues (and PRs) from our own repositories #159749
Replies: 159 comments 280 replies
|
💬 Your Product Feedback Has Been Submitted 🎉 Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users. Here's what you can expect moving forward ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities. Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐ |
Oh... Now here's where the lazy/fatigued people will use this to their advantage, these feautures don't only create Issues, but systemically close off and Ignoor older ones. It's one thing to be ghosted in need of help as a user of many projects (that you want to acknowledge as useful and share) but it's anoher to 'rub salt in the wounds' of personal issues that get closed by bot!!! Encouraging less human interaction is their M.O. IMO, SMH. (＃`Д´) |
|
It has always been possible to use a stale-bot to disrespect users by closing their issues automatically on a timer. It doesn't incorporate a Large Language Model. Nor does an automated form response involve a Large Language Model. I do agree with you that their M.O. is clearly to encourage less human interaction though. :) |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
@corysimmons: pong 😉 |
|
gotta use copilot to create a bot to autodeny copilot |
im 99% sure they do, but managers are just hyped and they demand AI. |
|
peak |
|
Yeah @i-am-called-glitchy called it being a management issue. Our head of development wants us to go all-in on "AI" nonsense and I just want to smash my computer every time it's come up. |
(Myself) Speaking up for project users and not necessarily creators: Publically they (github) claim the main benefits but leave out the 'uno reverse' where the bots can close issues, pre-existing from it's system wide deployment, from users of the repo. I rather propper etiquette and communication than the owners/creators using your AI Messenger buddy to 'dump' your concerns/issues for you without a thought of a supporters feelings, this has happened in the same android/phone based repos I'm involved in, active use for potential OS porting/development (google free ofcourse). |
|
Shareholders hear about AI, become convinced that (insert product here) needs more AI features, then the managers tell the developers to make it. They have to make something related to AI, even if the developers know it's completely useless or actively harmful (and this "feature" is both). Ultimately the motivation is profit, not actually making a good product. Letting you block it would cause less people to use it, which means less impressive graphs to show off at the next meeting. Also, Codeberg is always an option, you get free unlimited storage/private repos, and avoid the constant corporate nonsense like this that plagues GitHub... |
|
I think there may be a editing error in your second full body paragraph- you suggest that the easiest way to waste everyone's time would be adding features to disable the waste of dev time that is Copilot PRs |
|
this seems to be fixed |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Repo owners must have control over when and where they use AI in the repo. |
|
By the way, they can use all of your public (and possibly private) code you upload to GitHub to train their Copilot, regardless of your license restrictions, because this is stated in their Terms of Service! |
|
If you don't want your code to be read (by an AI or human or monkey), don't put it on GitHub. |
It's not about it being read, it's about it being included in large datasets without consent, and about AI being used to generate complete issues and PRs. Codeberg and Sourcehut respect people not wanting that, and so should MS |
|
I love the hate AI gets, just because you don't know how to use it doesn't mean you have to neglect what's never going away.. Feels like 1920 all over again but with AI... I dare anyone to give me any issue, any Protocol. |
|
I went to
And in my settings page under Copilot Features, I had an initial issue where the page rejected my attempts to set Anthropic Claude and Google Gemini to "Disabled". It appears to work now having closed the tab and opened a new one, but that was alarming to see... Still, two entries in that settings page are locked at Enabled, so it is impossible to disable "Copilot in GitHub.com" and "Copilot in GitHub Desktop", despite "Show Copilot" being disabled and helpfully hiding all the UI elements that had shown up. |
|
FYI, this only applies to PRs created by their agent (when you assign Copilot to an issue - only available through the more expensive Copilot Pro+ plan, not the tier that is provided to maintainers of popular projects and stuednt), not when a user creates a PR with the help of Copilot through prompts and PRs the finished work. Separately, for reviews (when you request a review from Copilot), |
|
Interesting, thanks. In my testing, I was able to block copilot-swe-agent but not copilot-pull-request-reviewer. I wonder if it's possible both bots are a special system construct, and some random github user coincidentally made an account named copilot-swe-agent on March 14. |
If so, it's a bug. Because when I click onto the username on logs, it redirects to the profile. |
|
Ah, yeah, I don't think a bug would do that! |
|
Sorry for the necro, at this point it seems copilot-pull-request-reviewer has been converted to an organization, thus not blockable. |
|
Please consider making this opt in, so that org and/or repository owners can have a choice. Or, if that's really not feasible, could there be an option to opt out? |
|
So you're telling me that JEP 369: Migrate to GitHub, which has been delivered was not about migrating to Git Hub? Cool story. They do use a dual-setup with bridges, which has now proven to have been an extremely smart choice. You can try to nit-pick but it won't change my actual argument: there's reasons why for every self-hosted top-project, there's 1,000 others on GH. You can read many of these reasons on the aforementioned JEP, which I'll link to again for your convenience: https://openjdk.org/jeps/369. |
|
Self-hosting is not an option for everyone. People do not self-host for the same reason that they do not grow their own food, build their own houses, or sew their own clothes: they do not have the time, resources or even skills to do this as well as professionals. |
That is correct, you can read all about how it was not about migrating to GitHub in the section:
"At this time" should be a dead giveaway. |
Cool story. Perhaps you may have noticed that I agree with you, and the current conversation is actually about whether self-hosting is a valid option for a minority group of professionals with funding? |
Right, but a lot of people here do have those skills, and supporting OSS with resources and skills that others can provide or pool is perhaps a more sustainable long term than people think. Eg, Codeberg for repository hosting, and sharing compute for runners for those that have those resources, donating to help fund where able etc, skills to help people setup. Currently sharing runners is a bit cumbersome, but that could be something Codeberg or others could change. Myself and other homelabbers I'm sure would be willing to donate compute, or skills. |
|
Legal advice often begs and commands that software is not exposed to the untested minefield that is AI. If a worker is not allowed to expose the code to AI... It'll be a hell of a day in the office if the entire org's is suddenly fair game. |
|
https://github.com/orgs/community/discussions/148571 Also see here for the legal concerns discussion. Unsurprisingly, Github hasn't responded yet. |
|
Here's the predictable result of this change: every single repository that a) is open, and b) is remotely large, is going to get DDOS'd by people submitting genAI issues against it. As a consequence, they will have to close the issue tracker, which will hurt GitHub. I understand that y'all are being told by your superiors to add genAI everywhere, and that you need to keep your jobs. Help us keep ours as well, by giving us the tools to stem the ongoing flood. |
|
I'd like a simple yes/no option to enable/disable CoPilot on GitHub. I am sure there are more refinements - eg: enable for A not for B etc but it's too intrusive in its current form. I think the idea of bots being able to report "issues" is ridiculous - but I really appreciate the Codeberg mention as I hadn't heard of them before. |
|
@kblaschke , Forgejo/Codeberg is a fork of Gitea. I am not qualified to evaluate the differences between them technically, but if you look closely at the Gitea web page you will realize Gitea may not be the #1 choice if you're trying to avoid services that use generative AI. |
|
The technical differences are (at least for now) very minimal. Forgejo came into existence due to differences in views about governance. They later became a hard fork because of rising tensions. Forgejo is definitely very nice to work with though! |
|
@RivenSkaye when MS bought GH into their butcherhouse, the difference in this and the alternates were very minimal.... strange?? |
|
There is surprisingly a single setting that can hide most Copilot "features" from the UI, the problem is it's opt-out and doesn't stop other people from using it, even when it's used to make an AI-generated issue on your own repository. |
|
The initial comment asks for "a single setting to disable it entirely" and not for a setting to "hide most of it but not all, and only for themselves" |
|
EDIT: The suggestion to use Copilot, seen on the screenshot below, has been removed. I'm not removing it from this issue because keeping historical context is important, but I also don't want people thinking this is still true, so I've added this edit note before my comment :P I just noticed that it's part of the standard "Create new issue" page. I can't wait for people to start creating issues that aren't even real because AI hallucinated something from the description given by the user :/ Please, GitHub, allow us to hide these from our issue trackers at least! |
|
Don't worry, I tend to write walls of text too 😄 Usually not sectioned, I guess, but I imagine you probably wouldn't be classed as AI. Current AI models imo just have a certain style (linguisticaly too, not just form-wise) of writing things that you are unlikely to replicate by coincidence. |
|
Oh, beautiful. Using that will also happily ignore the issue forms on your repository that you've spent ages on creating so that users will actually give you the info that you need 🤡 Oh FFS! |
|
@JackAtOmenApps @JackAtOmenApps @foosel FYI
|
|
Yeah, one of those maintainers was me. |
|
Thanks for that ❤️ |
I tried creating an issue on my own repo through Copilot and I ended up as its author, not Copilot, so this might not work. |
|
When you did this, was the comment history of you querying the bot— or any other paper trail which would allow the repo maintainer to detect that you used the copilot feature to create your submission— left behind? |
|
@mcclure, the issue can be seen here: Cog-Creators/Red-DiscordBot#6575 I can't find any other visible indication of the fact that it was generated in either the UI or API (https://api.github.com/repos/Cog-Creators/Red-DiscordBot/issues/6575), but feel free to check for yourself. |
|
Thank you, so that's extremely alarming. Not only does Github provide site-integrated tools that allow users to submit fake, machine-generated issues and PRs in violation of my project's submission rules, they then cover up the fact the tools were used in the first place, preventing me from enforcing my project's rules manually. This increases the maintainer load of detecting and removing this content even further. I'm going to have to basically introduce a verbal CAPTCHA. |
|
Some organizations have policies preventing use of generative AI, especially while concerns around rights are being debated in countries around the world. Making this feature opt-in would give those organizations a way to avoid someone inadvertently getting in hot water with their boss because they accidentally accept a PR. |
|
As acdha says making copilot issue/pr support opt in would be infinitely better than making it opt out. However Microsoft has declined many previous requests to allow even opt-outs on other parts of the copilot feature, and both GitHub and VSCode have at one time or another added copilot disable buttons which later copilot interface nubs simply ignore. So I just assumed, when submitting the feature request, that they would not even consider something so pro-user as making their planet-melter tech opt-in. |
|
https://github.com/orgs/community/discussions/148571 Also see here for the legal concerns discussion around co-pilot, especially the questionable training data. Unsurprisingly, Github hasn't responded yet. |
|
There is already a huge problem with low-effort AI-hallucinated issues that plague FOSS projects, that are costing the maintainers a lot of time to filter through to the point of burnout. This will only make it worse. Enabling and even actively pushing users through aggresive marketing and pop-ups towards doing exactly that is extremely hostile UX change for maintainers, to the point where projects will have to consider either closing issues or flat out moving away from this platform, which at this point I absolutely support. |
I agree, As stated previously, a somewhat formal conversation seems to be dwindling (by design IMO) using Ai as a MITM pimp to reject or accept issues as they are experienced. Power is given to the bot to close Issues that aren't even solved. Very dangerous for serious security or privacy functions in any project as you stated, even potential censorship in extreme cases. Not too far from impossible to manipulate human interaction before completely replacing it. |
As much as I agree with the first the other points, AI safeguards are often excessive and don't stop people from using an uncensored model. You can take illegal pictures with a camera, hack someone with a Bash shell and hit someone with a hammer, why put safeguards on AI and not those? |
|
It is possible to ethically use:
|
Because a hammer doesn't represent a credible existential-threat to humanity. Check out Roman Yampolskiy's interviews or https://gstonepress.carrd.co/ for some of the many experts extremely-worried about AI safe-guarding. |
|
I think this Github issue would very quickly turn into a ideological joust if we let conversations derive that much from the original point. It'd offer many anchor points for AI-apologists to hang onto and/or make inaccurate comparisons or call people Luddites. It may also be less convincing to the people taking decisions at Github, since they are clearly convinced they know what their customers need better than the customer themselves. Instead, I recommend sticking to the very clear, unalterable, and inarguable facts: outside of any ideology, slippery slope theory or abstract morals, AI-generated code and issues are spam and trash which make life harder for everyone, costlier, at no benefit. I feel like harping on this and this only is more likely to resonate with everyone, no matter if they're a techbro or not. (not that I have much hope it can change anything, there's too much money involved and the decision takers clearly need to justify this investment somehow with so-called innovation, even if it is a pure negative -- what matters is the marketing spin they can put on it. But we should try nonetheless!) |
|
I don't think I have the repeat again what has been said previously or in the original post, but I will. Pushing this on OSS contributors is one of the first worst thing that Github could do. This should be opt-in not opt-out. |
|
It's the second thing, actually. |
|
The issue here is it's not even opt-out (not that that isn't a problem too of course) |
|
We would have to consider pulling all of our projects from GH if this becomes a problem and there are no tools to address it. I hope GH and Microsoft can get into their senses that AI will not solve our problems, especially when we don't want it to. We spent 4 years building a good contributor culture in our projects and we'd love it to continue without forcing AI down our throats. |
|
First Google Code, now Github... not the first, not the last. |
|
Honestly, I think I'm just going to leave github and replace any of my active projects with a readme containing a link |
|
@alicealysia, this is a good approach. Check out an example of people doing this: https://github.com/conservancy/npo-ledger-cli. |
|
Thank you, also linked to some alternative resources. Wound up paying sourcehut a bunch because it's nice to just, have a place to dump my code. |
|
If GitHub won't provide a way to opt out of other people's AI-generated issues and code, you can always try making a This gets picked up automatically as a repository-wide instruction set and basically tells Copilot to refuse everything with a "nothing else matters" for added weight, hopefully rendering it useless. |
|
Why would it be impossible to introduce a per-repository setting (with per-user/organisationd defaults) such that if set and somebody mentiones that project on https://github.com/copilot, instead of actually processing the prompt, auto-reply with a message like
? 😉 |
|
@MisinformedDNA You continue to defend AI as if you had a personal emotional stake in it, to the point of being blind to both the original opening post, and refusing to accept, despite having been told, that many people not wanting this use AI daily, know AI well, are sometimes AI researchers, and still don't want Github to push this feature. This is unproductive, because even if you couch your words in polite language, they still are an ad hominem; you're essentially accusing people of being against something because they don't know enough. Instead of engaging with the argument, you're dismissing it on the basis of perceived lack of knowledge, character, or motive of the people speaking (whatsmore, without even asking about them). But it's even more unproductive than that; If it was just ad hominems and not respecting what people say, it'd be one thing; but it's worse because you do not care at all about the point people are making, and only want them to say AI is "good" somehow. It's just taking the conversation astray, detracting from the point, just to satisfy some kind of personal ego/pet peeve thing. Just completely off subject. No one here cares if you like AI or not, or if they should like AI or not. When you feign to go back to the discussion, you still do not engage with it with any level of honesty or integrity. Of course, making things "easy" is the point. You speak as if making things "easy" is meaningless. If it is "easy" to travel from Paris to New York because we have planes instead of horse, people do it more. Making things "easy" means people do something more, is the entire point. This shouldn't need explanations. There's no need to have "AI" fix it, Github can just not do the thing. I suggest you please engage with the argument and stop moving the conversation elsewhere, to battle imaginary windmills. Or, if you are unable to engage rationally, simply do not engage with the conversation at all; you certainly have better to do with your time. |
Besides-that much-more has been-offered in this discussion since it-started back in May. Him asking how is done entirely in bad-faith, either deliberately or because he's unable to do other-wise. There's no point in engaging any-more, he's also a wind-mill. |
|
What a funny workaround |
|
Wanting to disable Copilot PR reviews doesn't need to become a larger argument about AI use. The problem is that adding an AI to review your own PR incentivizes those creating the PR's to be less thorough and have Copilot sort out their own code suggestions in realtime on the public repo's PR page. This results in annoying clutter that the dev should instead work through on their own, offline! Or at the very least, in a private mock-PR environment. Any necessary code changes should be done before submitting their PR, so that way everyone else on the repo doesn't need to be subjected to what is ultimately a developer's learning experience. In short, a good PR should already be maximally self-reviewed, as much that dev is capable of, and then created/submitted to the upstream project. A repo maintainer shouldn't have to be involved with "the journey" that the PR makes while it's not ready. |
|
The sheer fact that copilot is explicitly excluded from being blocked on GitHub is just unacceptable.
Letting an "AI" bot loose on GitHub with no way to block it is like playing Russian Roulette with a cocked and loaded Stechkin Pistol set to fully automatic: Literally begging to get malware backdoors implanted (similar to
Should I not see a satisfactory response before Q1/2026 I'll consider GitHub to be lost and start self-hosting my repos & issue tracker to invite-only users and merely use GitHub as public slave mirrors (like The Linux Kernel) to keep my primary git* safe from bots DDoSing it.
|
The goal is to make money, and impressing investors with flashy new AI products that have lots of users gets M$ money. You can have lots of users if there's no way to turn the "feature" off! |
|
Github is a subdivision of Microsoft AI now so this has exactly zero chance of getting fixed. I recommend moving to Codeberg. |
|
In my opinion, people should start moving their repos to Github alternatives that either don't have AI or it's an opt-in feature. For me personally, I'm moving away not only from Github, but literally from anything related to Microsoft. That means away from Windows, Visual Studio, VS Code, C#, .NET, Outlook etc. I don't want anything to do with a greedy company that doesn't respect me and it wants to suck all my data to train their AI models with the end goal to replace me with bots. |
|
Countless people have already said this, but a good place to move away from GitHub to is Codeberg. Feature-wise, it has all of the same features you would ever need from GitHub (issue tracker, CI, Projects, you name it), but without anything of the troublesome AI support. It's basically the old GitHub mixed with the new one without any of the greedy trash from at the moment. |
|
It's just unfortunate that it's impossible to move over large, pre-existing projects to other languages. And not to mention companies that have a long standing ecosystem around it. You can't just rewrite everything all at once in such a situation, and even if you could you'll lose valuable contributors/colleagues in doing so |
|
Moving away doesn't mean to undo every mistake one has done on the past. If you have a project in C#, you can maintain it in C# but migrate the repo to Codeberg and maybe even stop using Visual Studio for development. And for new projects, you might want to consider another language. |
|
The companies angle was very much targeted at being locked in due to both the team and the existing bits and pieces. For private projects it's an easy choice, but those are also not the biggest victims of the poor decision making that got us here |
|
Mono exists. If the dotnet community genuinely feels like this is a problem, they can choose to revitalize interest in mono, migrate their own workflows to it and make sure that its development story is robust. |
|
If you want an alternative to GitHub Pages, I made https://grebedoc.dev. |
|
I considered plugging it here, but wasn't sure you'd want the added attention and server load |
|
It's been on HN and Lobsters already, it's fine. (Plus, I made it to be useful.) |
|
This is never gonna happen. |
|
Last paragraph of your message. I wager it's a typo trying to hit shift when phoneposting? |
|
It’s a fairly common typo among non-native speakers. A little unfortunate in this context ^^ |
|
That's really unfortunate... and yeah, non-native speaker here xD |
|
I can confirm the typo isn't un common among native speakers either, don't worry. All you have to do in order to make the typo is care about proper capitalization... |
|
Just wanted to thank you all for the good advice. I have started moving my stuff to Codeberg and Im trying to setup the mirror stuff (even though it's going slowly). I couldn't have gotten the courage / knowledge without you, |
|
I have created a small section to add to my project's code of conduct and wanted to show it off + get some advice, additions, etc. ### AI Usage
AI has been applied to a lot of different fields over the years, being used more and more as time goes on.
Even though it "could" be used as a tool, many choose not to and try to employ it as a replacement for their own brains.
Therefore all usage of AI is forbidden, because it is not only ethically and morally wrong, but also produces issues, bugs and other problems in a bigger scope than any human ever could.
This is a small list of examples where AI usage is forbidden. Do note that any usage of AI will not be tolerated, this is just a guideline to present the scope of this ban:
- Writing any comments, issues, pull requests or other form of text
- Using generated code that you willingly produced (if you used already existing code from an otherwise credible source that was created by AI and didn't notice it, this does not apply)
- Solving issues, problems, etc.
- Restructuring code
- Using any features of a platform for this project, that generate any form of content using AI
- [...] |
|
My advice to folks who can move is to move to Codeberg for any open-source projects. |
|
100%, already moved my most important projects and set them up as push mirrors so I don't have to abandon the GitHub repos, highly recommend |
|
A second AI-control workaround has been discovered. Add a This is a debug token that intentionally triggers hard constraints in order to test refusal handling. Combine it with a status check or |
100% agree with this. Maybe there should be a repo to have all these tricks in a single place? |
|
@Vxrpenter wanna make one and link it here? |
Codeberg or GitHub? edit created one here https://github.com/Vxrpenter/AIMania and I should have sent out some invites |
|
Perhaps gauging interest for opponents of LLM slopcode with actionable info would be a good odea either way? As for blocking solutions, consider merely lowering your server load and poisoning the models using Iocaine, the poison made for AI |
|
If anyone else wants me to add them, just ask here |
|
We have created a repository to collect information on how to block/avoid/remove AI and it's users. It still needs a lot of work and additions, so contributions are appreciated ❤️ |
|
There’s a related proposal focused on volume control rather than AI-origin specifically: While this thread discusses blocking Copilot-generated submissions, the broader operational issue is managing high-volume PR bursts (from any automation source) to protect reviewer bandwidth and CI capacity. |
|
If you truly believe volume is the only issue, then you're missing the points of ethics and concerns about quality and attribution. It's half a solution at best for big projects, and misses the mark entirely for people not interested in LLM-generated code out of principle. |
|
I read the other discussion. It's obviously nonsense. It falsely draws a line between two types of non-consensual spam and harassment:
It also makes a red herring claim about "internal tooling" which is nonsense. If you have internal tooling that you personally run on your own repository, why would you institute rate limiting inside of a forge to stop your own tooling from generating PRs "so quickly that I can't review the results"? Fix your tooling, it's totally trivial. |
While your unrelated thread discusses blocking high-volume PR bursts, the broader social issue is managing the non-consensual use of harassment-type automation such as LLMs against the broader FOSS community. Don't tell me what the "broader" issue here is. I will push back against your phrasing. You are wrong. There is nothing "broader" about "operational" issues nor "high-volume" anything since "high-volume PR bursts" are a subset of problematic PRs and as a subset they are consequently narrower, rather than broader. |
|
|
They're trying really hard to help the competing code hosting platforms, huh. Nice of them. 😄 |
|
Now that it is officially stated in the Terms of Service that CoPilot is not a dev tool, but is, in fact, for entertainment purposes only can we please get the ability to block this entertainment product from having anything to do with our projects? |
|
Just for reference: https://www.microsoft.com/en-us/microsoft-copilot/for-individuals/termsofuse
|
|
Keep in mind this is the TOS for Microsoft Copilot. Here we're mostly talking about things like GitHub Copilot Pro, Github Copilot Business, Github Copilot Enterprise, Github Enterprise Copilot Business or Github Enterprise Copilot Enterprise (sigh). So while sharing the same name, Microsoft Copilot and Github Copilot (as well as Microsoft 365 Copilot) are entirely different products. |
If you're not paying for CoPilot Pro (which I assume most people posting here about wanting to be able to block CoPilot aren't for obvious reasons) your CoPilot usage is governed by the regular Microsoft terms of service. |
|
Could you please move the discussion which TOS govern a service that nobody subscribed to this discussion wants to use to a separate discussion? Thank you. |
|
YES PLEASE GIVE US TOOLS TO PREVENT DUMB VIBE CODERS FROM SUBMITTING PR |
|
I want to join this discussion and stating my deep frustration with AI generated issues and pull requests on GitHub. I'm 100% behind FOSS and accessibility, but I'm afraid there needs to be some gatekeeping tools for opensource maintainers granted. Hence I'd like to expand this topic beyond Copilot. There are a lot of people creating GenAI slop issues/PRs. Just today a bot account (that was registered today) posted a hallucinated security report to the issue tracker of one of my projects. Not only was it pure slop, it was also ignoring the policy to mail security vulnerabilities to the associated inbox. Of course, I've blocked and reported all of these slop accounts. As a maintainer of a project with over 1600 stars, spammers like to target my project. Still this amount isn't that big compared to other top tier FOSS projects, so the slop is even worse there (I guess we are all aware of the slop DDoS inflicted on the cURL project and I want to provide my deep sympathies with Daniel Stenberg and his team). Proposal of not-that-optimal opt-in tools for FOSS maintainers:
I personally have already disabled PRs because of the harm and danger vibe-coders are inflicting on FOSS projects. In any case, GitHub needs to act against these floods of slop contributions and accounts. Unfortunately, whenever I reported an obvious spammer account to the GitHub support, they never took action against them. There is still a very obvious GenAI bot active which keeps spamming repositories with unsolicited nonsense reports (I'm refering to the lighthousekeeper bot). Please GitHub, act now! |
|
Have the option to limit what level of karma is needed to open PRs and issues, or just filter by it. |
|
Any news about this? It is really important to address the issue reported. |
|
I guess to Microslop it's more important to slop everyone even when they don't want to be slopped, both by feeding projects into the slop machine for training and by slopping the issue submissions... |
I agree, my projects are on codeberg. The problem is that too many important projects are on github. |
True, but since it is not really your project, the slop PRs are also not really your problem. I mean, it becomes a "your problem" if a project you depend on goes down the drain because of slop, but then the maintainers in charge will hopefully react soon enough and if not, then you're probably better of not to trust their project in the first place. Personally, I'm trying break free of the circle of enshittification, currently by giving https://radicle.network/ a try. |
|
Microslop didn't even give gitslophub any IPv6. It's not a serious platform in 2026... |
Next to A"I", their focus is on making GH enterprise friendly, so that they can finally drop the dying dumpster fire Azure DevOps is (e.g. Support non-RSA keys for SSH authentication, unresolved since October 2018). And enterprises still are on IPv4. And the unfortunate ones that want optimized IPv6-only CI runners, those just gotta foot the extra bill for IPv4 connectivity or, better, hush-hush back to CI runners hosted by Microsoft which then helps to sustain Microsofts meagre 20 % cash flow. You see, Microsoft is serious (about their interests) and if we are too (about ours), we have to act. |
and others
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Select Topic Area
Product Feedback
Feature Area
Issues
Body
I find the following two news items on the front page:
https://github.blog/changelog/2025-05-19-creating-issues-with-copilot-on-git.832008.xyz-is-in-public-preview/
https://github.blog/changelog/2025-05-19-github-copilot-coding-agent-in-public-preview/
This says to me that github will soon start allowing github users to submit issues which they did not write themselves and were machine-generated. I would consider these issues/PRs to be both a waste of my time and a violation of my projects' code of conduct¹. Filtering out AI-generated issues/PRs will become an additional burden for me as a maintainer, wasting not only my time, but also the time of the issue submitters (who generated "AI" content I will not respond to), as well as the time of your server (which had to prepare a response I will close without response).
As I am not the only person on this website with "AI"-hostile beliefs, the most straightforward way to avoid wasting a lot of effort by literally everyone is if Github allowed accounts/repositories to have a checkbox or something blocking use of built-in Copilot tools on designated repos/all repos on the account. If we are not granted these tools, and "AI" junk submissions become a problem, I may be forced to take drastic actions such as closing issues and PRs on my repos entirely, and moving issue hosting to sites such as Codeberg which do not have these maintainer-hostile tools built directly into the website.
Note: Because it appears that both issues and PRs written this way are posted by the "copilot" bot, a straightforward way to implement this would be if users could simply block the "copilot" bot. In my testing, it appears that you have special-cased "copilot" so that it is exempt from the block feature.
So you could satisfy my feature request by just not doing that.
¹ i don't at this time have codes of conduct on all my projects, but i will now be adding them for purposes of barring "AI"-generated submissions
Guidelines
All reactions