Skip to content

Add AI policy - #7259

Merged
westnordost merged 6 commits into
masterfrom
ai-policy
Oct 9, 2026
Merged

westnordost merged 6 commits into
masterfrom
ai-policy

Conversation

@westnordost

Copy link
Copy Markdown
Member

Here is a draft for a relatively liberal AI policy.

Opinions?

Here is a draft for a relatively liberal AI policy.

Opinions?
@westnordost
westnordost marked this pull request as draft October 9, 2026 11:45
@matkoniecz matkoniecz mentioned this pull request Oct 9, 2026
Comment thread AI_POLICY.md
@matkoniecz

Copy link
Copy Markdown
Member

maybe mention that content with undisclosed LLM usage is spam and will be handled as such?

or is it better to leave it undefined?

@Amaanprobably

Copy link
Copy Markdown
Contributor

In terms of PR desc -

  • Should be written entirely by a human, though could be modified/fixed by AI? (for grammatical or/and technical correctness, especially considering English isn't everyone's first language)

  • I think if the contents of the PR itself are "AI-generated" (with none to minimal human involvement), it should be declared at the start/top as to signal to the reviewer about what to expect.

  • If it only had "AI usage", like proofread, debugging, grammatical errors, etc. but the contents were mostly human created, it should be fine to declare at the end/bottom?

Comment thread AI_POLICY.md
@matkoniecz

matkoniecz commented Oct 9, 2026 •

Copy link
Copy Markdown
Member

Should be written entirely by a human, though could be modified/fixed by AI? (for grammatical or/and technical correctness, especially considering English isn't everyone's first language)

I would say that if LLM was asked to list problems and it was taken into account (rather than followed blindly) it does not need to be disclosed at all.

If suggestions were blindly accepted or new "fixed" version was copy pasted and replaced previous then it is now LLM generated.

This is my personal opinion at least.

@Amaanprobably

Copy link
Copy Markdown
Contributor

I would say that if LLM was asked to list problems and it was taken into account (rather than followed blindly) it does not need to be disclosed at all.

If suggestions were blindly accepted or new "fixed" version was copy pasted and replaced previous then it is now LLM generated.

This is my personal opinion at least.

Well I agree with you.

A human's ability to explain their own changes does act as a validation mechanism.
Their explanation would make it evident whether they actually understood what they were doing or simply asked the LLM to explain its own suggestions for them.

@matkoniecz

Copy link
Copy Markdown
Member

And often LLM instructed to do X will also do A, B, C and Z.

Quite common sign of unsupervised LLMese in PRs is that it start fiddling with many unrelated things and refactor unrelated function in the same file, and puts it into a single commit.

The same often happens with grammar fixes with text becoming claudey corporate pseudo-friendly.

@westnordost

westnordost commented Oct 9, 2026 •

Copy link
Copy Markdown
Member Author

maybe mention that content with undisclosed LLM usage is spam and will be handled as such?

or is it better to leave it undefined?

IMO, better undefined. We don't need to write what happens when people don't follow policies, it is self-evident and/or in the judgement of repo members.

I would say that if LLM was asked to list problems and it was taken into account (rather than followed blindly) it does not need to be disclosed at all.

Yeah, on non-disclosure. I feel that is a matter of course. I'd wage that most people use LLM chatbots to some degree. And stuff like rubber ducking, asking about certain APIs, workarounds for certain platform bugs, stuff you would have searched for on StackOverflow 5 years back, don't need disclosure at all, IMO.
Heck, even search (in API references) includes AI responses now, which are often actually very helpful!

That's not something that needs to be disclosed, and I think it is so evident that it doesn't need to be mentioned. We are not writing legislation after all, that needs to be airtight in its definitions, but for humans (and LLM bots, I guess).

@westnordost

This comment was marked as off-topic.

@matkoniecz

This comment was marked as off-topic.

@westnordost

Copy link
Copy Markdown
Member Author

I think if the contents of the PR itself are "AI-generated" (with none to minimal human involvement), it should be declared at the start/top as to signal to the reviewer about what to expect.
If it only had "AI usage", like proofread, debugging, grammatical errors, etc. but the contents were mostly human created, it should be fine to declare at the end/bottom?

After we talked about what would even have to be disclosed and that the PR description needs to be written by a human anyway, would you still think it necessary to add a paragraph about it? If yes, why, what would be the use? And also, if yes, do you have a suggestion for wording?

@geographybuff

Copy link
Copy Markdown
Contributor

I just feel like the concern around AI models is misplaced, because of the framing that AI makes more work for reviewers. If the reviewers aren't using AI, then yes. If they are, then you get the best of both worlds.

Take for example apache/datafusion. 12,626 merged PRs. Both of my AI PRs were merged, after passing 42 and 43 Github Actions checks (free on public repos) and being approved by an AI reviewer before a human maintainer merge. That really reduces the load on human maintainers. And datafusion does not have a ban on AI-written PR bodies, though it's certainly not for lack of experience reading them. I'm pretty sure most technically advanced repos with high PR volume don't have a ban on AI PR bodies.

Not saying you have to port over 42 repo-specific Github Actions PR checks overnight. But this repo has zero. I acknowledge @FloEdelmann 's comment noting that AI tagging could be automated. That could be a great place to start. On the same line, a lot of Github Actions checks to make sure the apk and other packages compile without errors would be a wonderful path forward; not simply cracking down on tools that can be genuinely powerful for the repo and lower the barrier for human contributions.

@westnordost

Copy link
Copy Markdown
Member Author

I don't want automated review. I'd never let another agent review and then even merge a PR without having passed human eyes. I think the draft AI policy makes it clear my standpoint on this as a maintainer. Maybe it does not reflect the standpoint of all regular contributors.

@Amaanprobably

Amaanprobably commented Oct 9, 2026 •

Copy link
Copy Markdown
Contributor

After we talked about what would even have to be disclosed and that the PR description needs to be written by a human anyway, would you still think it necessary to add a paragraph about it?
If yes, why, what would be the use?

Well AI has its own benefits, and in certain scenarios it is much more efficient than humans (say mathematical calculations, algorithms, etc), so tome, personally, it speaks more about correctness of said algorithm.

Also voluntary disclosure is much better than no disclosure, as LLMs (currently) abide by it, even with the fully AI-generated content I have seen (observing the drive-by guy from a few days ago), the agents often describe themselves as "AI-assisted with human review."

So it makes it easier to spot potential AI-generated spam and deciding whether its worth the effort.

It obviously isn't a guarantee of quality, nor should it automatically discredit a contribution, but it gives maintainers (and other reviewers) more context before they invest time reviewing it.

And also, if yes, do you have a suggestion for wording?

Well I don't have a specific wording in mind right now, but the AI policy that stood out to me recently was Apache's gen-ai contributions policy.

We could copy the wording from there perhaps?

@matkoniecz

matkoniecz commented Oct 9, 2026 •

Copy link
Copy Markdown
Member

I just feel like the concern around AI models is misplaced, because of the framing that AI makes more work for reviewers. If the reviewers aren't using AI, then yes. If they are, then you get the best of both worlds.

I prefer to not get LLM spam (or kill it with fire) and to give genuine reviews.

Also, presumably you are not signing up to cover costs. Though that is least problematic part.

@matkoniecz

Copy link
Copy Markdown
Member

Maybe it does not reflect the standpoint of all regular contributors.

I would put some additional roadblocks (as seen from my comments) but in general I agree.

Even if recently I was contributing less regularly.

@westnordost

Copy link
Copy Markdown
Member Author

Well I don't have a specific wording in mind right now, but the AI policy that stood out to me recently was Apache's gen-ai contributions policy.

We could copy the wording from there perhaps?

Oh, I didn't mean to replace what I've written here with a policy copied from somewhere else. My question concerned your point 2 and 3 from this comment #7259 (comment) specifically. I.e. about the location of the AI disclaimer, and possible wording.

@geographybuff

Copy link
Copy Markdown
Contributor

I don't want automated review. I'd never let another agent review and then even merge a PR without having passed human eyes. I think the draft AI policy makes it clear my standpoint on this as a maintainer. Maybe it does not reflect the standpoint of all regular contributors.

AFAIK datafusion only does human merges too. The question is whether or not the human has the benefit of both the AI reviewer and also the fully deterministic Actions that check whether packages still compile without errors. It's hard for me to imagine why a maintainer wouldn't want a check that lets them know if an off by one error crashes the entire package, so that they can send back the PR quickly before even thinking of running it on their own machine.

It's possible that this just might not be a good fit for us. That's ok, and it happens in open source all the time. It just felt weird how it played out. In #7247 and #7249 I fully disclosed my use of AI. These PRs were both merged within 63 minutes with no complaints about AI usage. Typo checks are a great bellwether in my experience for whether AI contribution is welcome on an active repo (perfect counterpoint). Then the AI only became a problem later, after I spent two and a half hours on #7256, which still has not yet gotten a substantive review. It spurned an extensive discussion regarding whether AI should be allowed, and no discussion yet raising any problems with the PR.

@geographybuff

Copy link
Copy Markdown
Contributor

Also, presumably you are not signing up to cover costs.

Actually, yes I will: as long as Github maintains its current policy of free Github Actions for public repos, and as long as the repo remains public, yes, I will cover your entire Github Actions bill for public repos.

@geographybuff

Copy link
Copy Markdown
Contributor

Well I don't have a specific wording in mind right now, but the AI policy that stood out to me recently was Apache's gen-ai contributions policy.

I support that policy verbatim. It signals that maintainers take the risk of AI bloat seriously. This policy also does not prohibit AI-drafted PR bodies. Apache's policy permitted me to draft my AI PRs there, which were merged.

@Amaanprobably

Amaanprobably commented Oct 9, 2026 •

Copy link
Copy Markdown
Contributor

Oh, I didn't mean to replace what I've written here with a policy copied from somewhere else. My question concerned your point 2 and 3 from this comment #7259 (comment) specifically. I.e. about the location of the AI disclaimer, and possible wording.

Ah, I misunderstood.

I'd put the disclaimer at the top when AI generated a substantial part of the contribution, and at the bottom when it was only used for minor assistance, making potential AI-generated spam easier to spot, as non-disclosure makes it easier to get away with.

As for wording, something simple like "AI was used to generate/refactor X using Y" should suffice, with the contributor clarifying how the changes were verified.

@FloEdelmann

FloEdelmann commented Oct 9, 2026 •

Copy link
Copy Markdown
Member

Then the AI only became a problem later, after I spent two and a half hours on #7256

This policy is not specifically in response to your PRs @geographybuff! It is specifically in response to #7257 (but also previous experiences with drive-by LLM-generated PRs). But general concerns about AI usage (including overly verbose PR descriptions, like yours in #7256) of course come up when discussing such a policy. Note that your spell-checking PRs (#7247 and #7249) did not have that overly verbose PR description problem. That those were reviewed/merged quickly and #7256 is not (yet) is rather a consequence of the amount and complexity of the changes.

@westnordost westnordost changed the title Liberal AI policy Add AI policy Oct 9, 2026
@westnordost

Copy link
Copy Markdown
Member Author

I'd put the disclaimer at the top when AI generated a substantial part of the contribution, and at the bottom when it was only used for minor assistance, making potential AI-generated spam easier to spot, as non-disclosure makes it easier to get away with.

Right, but would you also demand it from other contributors? (I.e. a reason to close the PR without comment if the disclaimer is at the wrong location.) It seems a bit harsh to me.

We already have in the draft policy:

  • must disclose AI usage
  • must write PR description yourself

Bots that ignore the AI policy and write a PR slop description anyway without providing any disclosure already violate the policy.

P.S: With "wording", I meant, what would be the suggested wording to add to the draft policy that demands this.

@geographybuff

Copy link
Copy Markdown
Contributor

AI can follow the policy to put the disclosure at the top. If it were a reasonable rule and they violate it, it could be used as a weed-out because they're probably not following the other rules either. The question is whether it's a reasonable rule, and I've already opposed that. I'm unsure that there's value in adding a "dot your t's and cross your i's" rule just to make AI prove that they will be obedient to us. Save that for the real meat that genuinely makes or breaks a PR: writing what testing you did or didn't do.

As for the denunciation list mentioned here, that seems no better than a total AI ban. Of course people will see things differently, so good internet sweeping bots (like mine) would avoid the repo if they interpreted that there would be a risk of their human being added to a denunciation list just because the typo PR doesn't go over well.

@Amaanprobably

Copy link
Copy Markdown
Contributor

Right, but would you also demand it from other contributors? (I.e. a reason to close the PR without comment if the disclaimer is at the wrong location.) It seems a bit harsh to me.

Well, yeah, you might be right. I don't necessarily think the placement itself should be grounds for closing a PR.
My intention was just to make disclosures more visible.

Given that the current policy already requires disclosure, I don't think we need an additional rule about its placement.

Comment thread AI_POLICY.md Outdated
Comment thread AI_POLICY.md Outdated
@mnalis

mnalis commented Oct 9, 2026

Copy link
Copy Markdown
Member

We should IMHO also update .github/ISSUE_TEMPLATE/* to require a checkbox stating that no AI was used (or alternatively; if it was used, which one, and to which extent)?

@westnordost

Copy link
Copy Markdown
Member Author

I have less problems with an automatically written bug report, if it is valid. Sure, it would still be against the proposed policy, but it hasn't been any issue so far, so I wouldn't want to complicate the process of creating issues for everyone else. We can change that if this becomes an issue.

Co-authored-by: Flo Edelmann <git@flo-edelmann.de>
Comment thread AI_POLICY.md
@westnordost
westnordost marked this pull request as ready for review October 9, 2026 15:38
@westnordost
westnordost merged commit 7db9229 into master Oct 9, 2026
@sargunv

sargunv commented Oct 10, 2026

Copy link
Copy Markdown
Collaborator

I just read through it, all sounds good to me (as a heavy ai user)

a tiny suggestion, I'd draw a distinction between draft and ready PRs (or clarify if there is no distinction), for example in my project's ai policy

Before you mark a pull request ready for review:

My workflow for my PRs here has been to first pair with the agent to produce a draft, publish the draft PR, review it line by line on GitHub, apply any refinements, delete and rewrite the agent's pr description, then mark ready for review.

I'm assuming that's acceptable; if it's not that's fine too, I can change my workflow

@westnordost

Copy link
Copy Markdown
Member Author

Fair enough, why not. I usually don't look at draft PRs unless specifically pinged, and I reckon that contributors might want to use the GitHub UI for reviewing their own PR before marking it as ready for review.

@mnalis

mnalis commented Oct 11, 2026

Copy link
Copy Markdown
Member

TL;DR: I too would argue that requiring AI to identify itself at the top (or even #AI label) is a good idea, both:

  • as a courtesy to other contributors who would prefer avoiding AI-generated stuff with minimal effort (without having to read the rest of PR text to find out that they wasted their time) , and
  • as a filter to avoid (potentially problematic) contributions which have not read the contribution policy (or chose to ignore it)

I'd put the disclaimer at the top when AI generated a substantial part of the contribution, and at the bottom when it was only used for minor assistance, making potential AI-generated spam easier to spot, as non-disclosure makes it easier to get away with.

Right, but would you also demand it from other contributors? (I.e. a reason to close the PR without comment if the disclaimer is at the wrong location.) It seems a bit harsh to me.

Well, perhaps, but perhaps not?

Take for example my occasional wall-of-text posts -- I was asked (and for a good reason! ❤️ ) that I provide TL;DR to them and to preferably put it at the top. Now, I guess my posts wouldn't be automatically ignored/hidden if I chose to just put TL;DR's to the bottom of the posts, but it seems like a reasonable courtesy that (noticeably) improves the workflow of the others, so I was happy to oblige (to everyone's benefit)!

The same would IMHO be the case for AI requirement to declare themselves at the top. Especially given that some (many?) people (spoiler: myself included) are much less likely1 to want to look at AI-generated(/heavily-assisted) code (or comments) than the human-written ones.

IOW, I would think that making the similar requests of AI as we make of other humans is (more then) reasonable.

In fact, I think #AI GitHub label would be even nicer, as it could be added after-the-fact by other contributors too, and would allow for easier automatic filter-out for those not interested to get involved with it.

AI can follow the policy to put the disclosure at the top. If it were a reasonable rule and they violate it, it could be used as a weed-out because they're probably not following the other rules either. The question is whether it's a reasonable rule,

Well, I think you nailed it with "probably not following the other rules either" filter. Is it reasonable on its own? I would say so (see above), but even if it was a totally unreasonable request on its own (like famous "all brown M&Ms must be removed from the bowl"), it would still function as very useful filter (as you yourself note) to detect potentially problematic contributions.

Footnotes

  1. e.g. I'm personally not interested in doing the reverse centaur work (like reviewing AI-written code) even if it was a decently paid job, and certainly not as a volunteer effort in my spare time. I might make a rare exception if some AI-made feature is exceptionally interesting to me, but generally I find it tiresome and off-putting. ↩

@FloEdelmann

Copy link
Copy Markdown
Member

For reference: @sargunv's suggestion about draft PRs was applied in bfd7e10.

@FloEdelmann
FloEdelmann deleted the ai-policy branch October 12, 2026 11:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants