How do we deal with AI-generated issues?

[dtomvan]

Github has announced that they will allow contributors to generate issues with AI: https://github.blog/changelog/2025-05-19-creating-issues-with-copilot-on-github.qkg1.top-is-in-public-preview/

I think we should carefully consider what to do about that, as possibly a bunch of bogus bug reports and/or build failures will come in. Github also said that they will allow users to submit multiple reports at once, to take the repetitiveness of filling in the forms out of the equation, possibly bringing us a lot of spam. As of now, we don't know what it will look like exactly, but I would like to bring it to discussion already as this repo seems to best when things have been spelt out. (re: #387072)

Github has not yet confirmed or denied that it will be possible to opt out of this, but users are concerned/suspecting that they will not be able to opt out, re: https://github.com/orgs/community/discussions/159749

So, what is our stance to these eventual Copilot-submitted issues? Do we:

• Waste no time and close all of them immediately?
• Talk to the submitter first to see if they actually have meaningful details? For example, Copilot will never be able to actually run nix-info on the reporter's system or generate something that is even remotely correct.
• Triage them ourselves, betting that there must be some truth to the issue as the choice to submit the issue has still been made by a human?
• Consider moving issues to somewhere else like gitlab/codeberg/forgejo?

I think there are a bunch of opinions to be heard here, but I haven't yet seen an issue raised related to this. Not trying to unnessecarily spark controversy here, I just think this development with GitHub should be considered. And also in general, is nixpkgs putting too much eggs in the github basket? The repo and all development happens on github and a lot of packages are written with fetchFromGitHub. Re: #409110 (review)

[Sigmanificient]

The problem is that even when asking to run nix-info, it isn't necessary for all issues type because some does not rely on system info at all (eg. request package update, module or even the blank issue).

Considering the number of issues has only kept growing (over 10k issue open now) it is possible that spam issue will get noticed for a while unless obvious enough to be closed directly. This can be especially bad if user can just ask to fill the system metadata with any of the thousand examples on other issues (or paste a pre-made text)

We currently have nothing set to close automatically "inappropriate issues" when missing metadata because it would probably be considered as quite rude, and would probably hide some very needed interventions.

[eclairevoyant]

• Copilot will never be able to actually run nix-info on the reporter's system or generate something that is even remotely correct.

Why not?

a lot of packages are written with fetchFromGitHub

Because the code is hosted on gh, what else would we use?

Anyway IMO handwringing about nonexistent problems is a waste of time, some users are already using AI to file issues and they are very easy to catch. If we don't see much obvious volume then there's not much to do other thna handle them individually.

[keysmashes]

Copilot will never be able to actually run nix-info on the reporter's system or generate something that is even remotely correct.

Why not?

Presumably a text generation tool seeded with e.g. the text "i get an error about glibc" cannot magically determine which version of Nix you have installed...

[ranomier]

@eclairevoyant As i understand, the issue is that copilot can create issues on it's "own". Meaning normally the user at least has to copy paste or use another service. But in this case the user just asks the AI to open an issue and it does it for them.

And as far as i understand it probably could do it with multiple issues over multiple repos.

This specific issue is still new to me, i may be mistaken :)

[Sigmanificient]

Copilot will never be able to actually run nix-info on the reporter's system or generate something that is even remotely correct.

Why not?

Presumably a text generation tool seeded with e.g. the text "i get an error about glibc" cannot magically determine which version of Nix you have installed...

Sadly there is not need to go that far:

[eclairevoyant]

Exactly my point. Just keep your eyes open (eg. 24.05 is unsupported) and treat them like regular issues unless there's nothing to act on.

@ranomier Unless you know the scope, shadowboxing is wasted energy. Again, unless we see massive volume, treat them as normal issues until they prove otherwise.

[dtomvan]

• Copilot will never be able to actually run nix-info on the reporter's system or generate something that is even remotely correct.

Why not?

Because, unless you use some agent which is ran locally and allowed to run commands automatically (and assuming that they copy the output exactly in the first place without drawing "conclusions themselves"), it will just make up something.

[dtomvan]

@ranomier that's exactly what is the case here, a user could say "I cannot run blender from nixos" and then copilot would go "i see there are 20 dependencies that could be the problem here, let's file 20 issues". This is of course hyperbole but still a lot of unwanted slop get filed. "Deal with them one by one" does not seem very productive to me.

Also I think that instead of calling this shadowboxing, I think this should be called "being cautious and having a healthy discussion". Daniel Stenberg, head of curl, encounters this problem a lot already and he has explicitly stated that they no longer want any AI contributions. Some links from their mastodon account:

• CycloneDX drops bug bounty program, toot
• Most recent curl Hackerone AI bounty, toot
• Curl AI policy

This is a very real and very time costing problem.

A very quick and easy thing to do is at least prohibit or strongly discourage filing these kinds of issues with Copilot in CONTRIBUTING as done in curl. Other projects are adopting these standards from curl too. Or in the issue template a new checkbox under "this issue is relevant to nixpkgs", "I have not used AI to submit this issue". Then we could hold reporters accountable.

[eclairevoyant]

• Copilot will never be able to actually run nix-info on the reporter's system or generate something that is even remotely correct.

Why not?

Because, unless you use some agent which is ran locally and allowed to run commands automatically (and assuming that they copy the output exactly in the first place without drawing "conclusions themselves"), it will just make up something.

Yes, it will, as I said it takes some vigilance to notice that e.g. unsupported versions are mentioned and we tell the user and then close such issues. The thing isn't that it's "not remotely correct", it's that it's 90% sensible and therefore appears fine if you're not paying attention. Moreover there are users running absurdly outdated systems that expect them to still work. So nix-info is not an effective filter for whether it's a bot issue vs someone ignorant of our release cadence, and if we treat it as such, it ends up being really rude to honest users who just don't know any better.

Hence, IMO we treat them as regular issues (assuming good faith) unless there's something obviously nonsensical about the issue, at which point we close it. If the same user files a massive number of issues or continues to otherwise spam, tag moderation.

A very quick and easy thing to do is at least prohibit or strongly discourage filing these kinds of issues

We already do.

Examples of unacceptable behavior by participants include:
...

• Wasting other people’s time with low quality contributions, including but not limited to LLM and bot spam

See https://github.com/NixOS/.github/blob/master/CODE_OF_CONDUCT.md#our-standards. If people post AI slop, moderation has the latitude to act accordingly.

For an extremely popular project, we get a visible but still relatively small amount of AI slop from my casual observation, which is why I consider this overall a non-issue until demonstrated otherwise. Curl had a different problem because they provided a bounty, obviously that provides some perverse incentives to spam as much as possible, but the NixOS Foundation doesn't offer such a bounty to my knowledge.

[dtomvan]

nix-info is not an effective filter for whether it's a bot issue vs someone ignorant of our release cadence

Never said that was the intention. I'm sorry if I didn't make myself clear enough. I meant that we can be thrown off by an incorrect version of nixpkgs mentioned for example. Then triage might take a lot of time due to some subtle discrepancy even though the facts given are wrong.

We already do.

Yes, but these things could be a bit more "in their face" when it comes to "LLM contributors" (like as I said as a seperate checkbox in the issue template). Because I doubt that anyone not willing to do the manual work to fill out the issue form will actually read through the entire CoC before they open their LLM/Copilot.

But I think I'd have to agree with you that this isn't as much as of an issue as I though. Moderating spam sucks, but that has always existed on the internet. I'll keep this open for a bit so that anyone who has something to add has the opportunity to do so.

[eclairevoyant]

Would it be productive to have an ai-likely label to track volume? (Though it'd be subjective.)

[dtomvan]

To attract moderators, I'd imagine it could help. You'd have to ask them though, whether or not they'd actually use such a label.

[pbsds]

Considering how the copilot code reviewer (instance: #413095 (comment)) clearly labels its output as AI, I expect this new issue creation flow from Github to do the same.