AI Policy

[niccokunzmann]

This project's health, progress and joy of engagement with each other and the source code depends on human beings and relationships. AI cannot replace this as it lacks consciousness.

Sometimes, we get PRs that are generated by AI.
This has a negative impact on our developers:

• feedback is ignored
• issues not understood
• one is lied to at times as there is made a claim to contribute a change but the code does not reflect this.

The effects are:

• eroded trust
• wasted volunteer time

We want to project the joy and good will of our maintainers and contributors and for that we need to take a strong stance against AI abuse.

The issue can be closed when there is a code of conduct for AI contributions:

• how to quickly flag up & close AI contributions
• how to deter new contributions from the same source
• how to allow false-positives to be handled by humans

See also

• PR #926 situation, need guidance #927
• Adopt a Code of Conduct for community health files #907
• Choosing a Code of Conduct #852

[SashankBhamidi]

Here's what I've learned from reviewing PRs and looking at how other projects handle this.

The pattern is pretty consistent. Someone ignores explicit instructions in the issue, submits before prerequisites are met, posts ready for review seconds after CI passes. No evidence they tested anything. The code doesn't match current main because they branched from outdated commits. Tests pass on their branch but test the wrong behavior. PR body reads like someone fed the issue to an LLM. When you point out technical problems, they either disappear or respond with generic acknowledgments that don't address what you asked.

Three or more of these together and you're looking at AI autopilot.

What other projects are doing:

Gentoo voted to ban AI-generated contributions completely in April 2024. Their logic: copyright around AI output is messy, LLMs generate plausible garbage that wastes reviewer time, and training data involves massive copyright violations. They decided protecting volunteer time matters more than accepting AI contributions. https://wiki.gentoo.org/wiki/Project:Council/AI_policy

Kubernetes takes the opposite approach. Use AI if you want, but disclose it in the PR description and you're still responsible for correctness and review burden. The contributor owns the output, not the tool. https://www.kubernetes.dev/docs/guide/pull-requests/

Apache Foundation and Linux Foundation both issued guidance in 2024. Both allow AI contributions but emphasize the contributor is accountable. Apache's legal committee specifically created documentation because of open source security concerns around generative AI. Linux Foundation is coordinating with other foundations to align policies. https://news.apache.org/foundation/entry/asf-legal-committee-issues-generative-ai-guidance-to-contributors and https://www.linuxfoundation.org/legal/generative-ai

Hacktoberfest got burned in 2020 when spam PRs hit 4 per hour. Now they require maintainer approval, contributors can label PRs as spam, two spam PRs disqualifies you, and there's a 7-day review window where approval can be revoked. Projects have to opt in with a topic tag. https://hacktoberfest.com/participation

What this tells me: the core issue isn't AI, it's accountability. Gentoo banned it because they don't trust contributors to validate AI output. Kubernetes and the foundations allow it because they put responsibility squarely on the contributor.

Process that makes sense:

First red flag PR: comment with specific technical problems, label needs-revision
Second from same person: close it, temp ban, point them to guidelines
False positives: let them explain their process, we decide

The real thing we're protecting is maintainer time. We're volunteers reviewing code, not validators for AI output. If someone uses AI and produces garbage, that's on them. Two strikes and they're out feels fair.

[SashankBhamidi]

Some specifics on implementation that other projects use:

Linux Foundation requires labels in contributions. "Generated-By:" for generative AI, "Assisted-By:" for predictive tools like Copilot. Human still owns the output but disclosure is mandatory. They also require enabling features that flag when output resembles public code to avoid license issues.

Apache goes further. Contributors must ensure AI tool terms don't conflict with Open Source Definition, use tools that identify similar training data and licenses, and verify third-party materials are compatibly licensed. Their legal committee created this specifically because of security concerns around AI in open source.

GitHub's community guidelines have a section on this too. Don't post AI content verbatim to inflate reputation, use your authentic voice, verify answers actually work with developer expertise, avoid misleading users with AI's authoritative tone.

Detection gets easier when you know what to look for beyond the obvious red flags. Can they explain reasoning behind implementation choices? Do they have a pattern of similar stylistic issues? When you ask specific technical questions, do they give substance or generic responses?

For maintainers dealing with this, template responses save time:

First flag: "Thank you for your contribution. To ensure quality, we need contributors to understand their changes deeply. Could you explain: 1) Why this approach over alternatives? 2) What edge cases did you consider? 3) How does this interact with [specific component]?"

Closure: "We're closing this PR as it doesn't meet our standards. Our project relies on genuine human understanding. If you want to contribute, start with a good first issue to familiarize yourself with the codebase and engage in discussions before implementing."

Where to document this matters. Add it to CONTRIBUTING.md prominently. Put a checkbox in the PR template: "I confirm this contribution represents my genuine understanding and was not primarily generated by AI tools." Brief mention in README with link to full policy. Reference in CODE_OF_CONDUCT.md if we have one.

The distinction between acceptable and not is clear. Using AI for brainstorming, documentation help, boilerplate, or code review suggestions is fine with disclosure. Human must understand, review, and take responsibility. What's not acceptable: wholesale AI-generated code without understanding, copy-paste responses to issues, using AI just to build reputation, claiming credit for work you don't understand.

One more thing on false positives since this came up. Non-native English speakers, different communication styles, people new to open source, and anyone who writes in ways that seem formulaic can get caught. Always assume good faith initially, provide opportunity for clarification, use multiple signals not just writing style, have an appeal process with human review, and document false positives to improve detection.

References:

• Linux Foundation policy: https://www.linuxfoundation.org/legal/generative-ai
• Apache guidance: https://www.apache.org/legal/generative-tooling.html
• GitHub community guidelines: https://docs.github.com/en/site-policy/github-terms/github-community-code-of-conduct

[SashankBhamidi]

Couple more things worth considering:

Contributor Covenant is working on v3.0 that will address AI contributions specifically. They're one of the most widely adopted codes of conduct in open source. Might be worth monitoring what they come up with before we finalize anything, could save effort on getting the wording right.

For the PR template, being explicit about what we expect helps everyone. Something like this makes the expectations clear from the start:

## AI Usage Declaration

- [ ] This contribution represents my genuine understanding of the codebase
- [ ] Any AI assistance used was disclosed in commit messages with "Generated-By:" or "Assisted-By:" labels
- [ ] I have personally reviewed, tested, and can explain all changes
- [ ] I understand I am responsible for the correctness and quality of this contribution

Pattern recognition is important. One questionable PR from someone might just be an off day or inexperience. Three PRs with the same problems - rushed submission, surface-level understanding when questioned, generic responses to feedback - that starts looking like a pattern worth addressing.

Something that hasn't come up yet: how do maintainers enforce this consistently? If we establish a policy, the people reviewing PRs need to know what questions to ask, what responses are red flags, when to escalate to closing a PR or blocking a contributor. Without clear guidance on enforcement, you end up with inconsistent application and contributors getting mixed signals about what's acceptable.

When drafting the actual policy document, breaking it into clear sections makes it easier to reference and enforce. Principles section covers why this matters - human understanding, maintainer time, project health. Guidelines section defines acceptable AI use and disclosure requirements. Detection and response covers red flags and the process for handling violations. Implementation covers where this gets documented and how maintainers learn to apply it.

This gives a structure to work from once the project decides which direction to take - somewhere between Gentoo's total ban and Kubernetes/Apache's disclosure-with-accountability model.

[SashankBhamidi]

Some practical details:

For the labeling, having a standard format helps. Linux Foundation uses commit message footers:

Generated-By: ChatGPT-4 (OpenAI)
Assisted-By: GitHub Copilot

Makes it easy to grep history if needed.

Timeline for enforcement: wait a week for response to technical questions on first offense. If they ghost or give non-answers, close it. Second offense from same person, close immediately and point to policy.

When the policy goes live, how do we tell people? We could pin an issue announcement, add notice to README temporarily. Contributors need to know the rules changed.

Track metrics: how many PRs flagged, false positive rate, successful appeals. Data tells us if the policy works or needs adjustment.

One thing not mentioned: what about contributors who used AI before the policy existed? Example, me: I use Copilot for commit messages and Claude at times. The difference is understanding what you submit and being able to explain it. Worth deciding upfront how pre-policy contributions get handled.

[SashankBhamidi]

Above research came from Google Search and Perplexity.

Turns out reading psychology books helps spot the difference between autopiloting and actual understanding. Applies to PR reviews too.

@niccokunzmann @stevepiercy Thoughts?

[stevepiercy]

• We are volunteers.
• Keep it simple and flexible.
• Don't require any steps. If a policy is violated, take appropriate action, move on.
• The contributor is responsible to make their case to maintainers, not the other way around.
• We can modify our issue and pull request templates as needed.
• I'd prefer to let other people and organizations work out some possible solutions, and we adopt and adapt the best one for our needs.