AI Contribution Policies

AI
,
1

Gitea

Starting a thread on AI Contribution policies – feel free to add addtional ones you find.

Gitea AI Contribution Policy

AI Contribution Policy

Contributions made with the assistance of AI tools are welcome, but contributors must use them responsibly and disclose that use clearly.

  1. Review AI-generated code closely before marking a pull request ready for review.
  2. Manually test the changes and add appropriate automated tests where feasible.
  3. Only use AI to assist in contributions that you understand well enough to explain, defend, and revise yourself during review.
  4. Disclose AI-assisted content clearly.
  5. Do not use AI to reply to questions about your issue or pull request. The questions are for you, not an AI model.
  6. AI may be used to help draft issues and pull requests, but contributors remain responsible for the accuracy, completeness, and intent of what they submit.

Maintainers reserve the right to close pull requests and issues that do not disclose AI assistance, that appear to be low-quality AI-generated content, or where the contributor cannot explain or defend the proposed changes themselves.

We welcome new contributors, but cannot sustain the effort of supporting contributors who primarily defer to AI rather than engaging substantively with the review process.

2

I think the most important point is disclosing one’s use of AI. The second most important point is that the contributor is ultimately responsible for what the AI creates.

But, yeah, all projects should accept AI-assisted contributions. If they don’t, folks will just use AI anyway and pass it off as their own work.

3

I wonder how important this declaration will be in the near future, as so much code will be written by AI. It seems we need some other metric to judge code quality …

One approach is to submit your plans with your code. I find it much easier to review a plan than code. This exposes the thinking (perhaps much of it by AI) behind the code. If the plan is solid, I don’t worry too much about the AI implementation.

Perhaps every project should have detailed requirements in AGENTS.md of what plans for the project should look like, where they are stored, etc. And a requirement for a plan for every significant PR would also improve human coding as well.

One thing I’m finding is Claude generally does a better job than me at the raw coding. However, the design or architectural level is where the problems usually occur. So I don’t think we need to be concerned about AI implementing low-level code, but rather introducing architectural problems.

4

Very solid points, and I really like the idea of submitting the plans with the code. The plan has much more value in the world of AI agents because they can be prompted to verify that the plan was properly implemented.

That said, in my experience, even Claude Sonnet/Opus 4.6 doesn’t always get the implementation quite right. I’ve seen it make subtle but silly API decisions even when the plan has reasonable levels of clarity and even if I’ve prompted it to ask me clarifying questions.

Here’s a popular AI-assisted change where the AI model silently omitted the __read_mostly macro, which is a kernel macro to improve memory cache performance. Now, one could make the argument that a human could easily make the same error. In this particular case, the code reviewer knew the contributor and made some assumptions about the code quality… and the reviewer’s lax demeanor led to the bug sneaking through and eventually causing pretty serious performance regressions. This is perhaps a case for declaring the use of AI assistance. It’s almost like saying, “hey, someone wrote this code on my behalf, so perhaps my reputation for higher quality should be questioned.”

On the other hand, AI agents will probably not be getting any dumber in the future, and I concede that the disclosure will likely become irrelevant over time.

To your point about planning vs. implementation… I have found great success going back and forth a time or two with the AI agent in the planning phase. Only when I feel like the agent has a deeper understanding for the intent of the change / feature do I cut it loose to implement it. But, like most humans, it still cannot handle very large changes gracefully. You have to break the problem down into smaller chunks.

5

Yes, it is powerful to have AI doing the research and collecting the details, while you do the thinking.

Have you tried the superpowers plugin yet? Really impressed with the brainstroming phase.

6

No. I’m not using Claude Code. Is it a Claude Code thing? I’ve been primarily using Copilot via GitHub. I use the Copilot CLI and other GitHub-based workflows.

7

Looks like superpowers is available for Copilot CLI:

8

Ghostty AI Policy

This one seems pretty reasonable.

It is discussed in this podcast:

9

Zig AI Policy

Andrew takes a pretty hard line:

Strict No LLM / No AI Policy

No LLM-generated content, whether it be code or prose.

No paraphrasing LLM-generated content.

No LLMs for editing, including fixing spelling or grammatical errors.

No LLMs for translation. English is encouraged, but not required. You are welcome to post in your native language and rely on others to have their own translation tools of choice to interpret your words.

No LLMs for brainstorming and then sharing the results of that brainstorming, even if you create the prose. If you use a chatbot to give you advice on a comment on the issue tracker, that comment is unwelcome.

No LLMs for finding bugs.

No talking about use of chatbot/LLM services.

10

More commentary on the Zig AI policy

To be able to provide impactful work a contributor needs to be familiar with the codebase and the problem space, and they need to be trusted by the core team to have thought through all the changes introduced by their PRs in order to strive for an optimal approach, rather than just submitting a random solution that happens to pass CI.

So while one could in theory be a valid contributor that makes use of LLMs, from the perspective of contributor poker it’s simply irrational for us to bet on LLM users while there’s a huge pool of other contributors that don’t present this risk factor.

The people who remarked on how it’s impossible to know if a contribution comes from an LLM or not have completely missed the point of this policy and are clearly unaware of contributor poker.

For us the ability to provide contributors with an engaging ecosystem where they can improve their systems thinking and interact with other competent, trusted and prolific engineers is a critical aspect of our business model.

As I’ve mentioned before, Zig is able to punch well above its weight funding class because we put huge effort in thinking about technical, social and business management issues that surround the project.

Contributor poker is a key part of our strategy and it’s in the project’s best interest to push back against anything that hinders our ability to play the game effectively. That being said, we are aware that there are still many unresolved issues and we plan to adjust our policy as we gain more insight.

11
12

Rust AI Contribution Policy

13

OE4T

This one looks very reasonable:

14

Linux Kernel

15

Linux Foundation

16

My stance is that good engineers who are good at using the LLM tools will submit code to open source projects. This is going to happen, it already happens. When used well and effectively, you won’t be able to tell what’s written by the LLM and what’s written by the human engineer. Regardless, I believe that the human who puts their name on the code as the contributor is responsible for the contribution.

If you submit slop, regardless of who/what generated it, you will get ignored/banned/kicked/removed from the community. If you submit quality useful contributions, your changes will get merged and you’ll be welcomed by the community.

Soon, the EU-mandated watermarking is going to be used against people in LLM witch hunts. Good engineers are going to get burned at the stake for contributing LLM-assisted code and not disclosing it, even though it’s going to end up being good code which no one previously thought was LLM-generated. This will be unfortunate and sad.

1 Like
17

Debian voted AI policy

The Debian project recently voted on 8 different AI policy options. The result is to permit generative-AI-assisted contributions, rather than impose a ban or special mandatory controls. The winning policy—“Responsible Use of Generative AI”—puts full responsibility for quality, security, licensing, and suitability on the human contributor submitting the work.

What passed

The General Resolution’s winning text says Debian neither endorses nor prohibits generative AI in development, package maintenance, documentation, or other Debian-published material.

Its core principle is tool-neutral: a contribution must meet Debian’s existing standards regardless of whether AI helped create it. A contributor is expected to understand, review, test, and revise AI-assisted output as necessary; blindly uploading generated output is explicitly characterized as inconsistent with Debian practice.

It also says contributors should:

  • Consider copyright, provenance, and license risks before submitting material.
  • Keep confidential material out of third-party AI services—especially embargoed security information, credentials, private discussions, personal data, and other non-public Debian information.
  • Discuss and gain appropriate consensus before large-scale automated actions, such as mass bug filing, patch submission, or broad code changes.
  • Disclose AI use where appropriate, but disclosure is encouraged rather than mandatory.

What did not pass

The ballot included eight policy alternatives ranging from outright prohibition to permissive use with varying safeguards.

Option Basic approach Result
A Add a Social Contract ban on direct LLM-assisted contributions Failed its required 3:1 majority
B Allow AI with legal, accountability, disclosure, bulk-change, and privacy conditions Passed simple-majority threshold, but lost to the winner in head-to-head ranking
C Ask contributors to avoid LLMs; prohibit AI-assisted messages to people and require disclosure Failed majority
D Permit AI for Debian-specific work with accountability, marking, and confidentiality rules Passed threshold, but not selected
E Responsible use; no special prohibition, mandatory disclosure, or separate AI regime Winner
F Cautious policy encouraging avoidance where practical Passed threshold, but not selected
G Permit assistive use but ban generative output as direct Debian contributions Passed threshold, but not selected
H Encourage avoidance chiefly on climate grounds Passed threshold, but not selected

The strict Social Contract ban received 144 votes over “None of the above,” versus 257 against it, so it was far from the needed 3:1 ratio. The winning option received 281 votes over “None of the above,” versus 126 against.

Why option E won

Debian uses a ranked Condorcet-style election system: rather than simply choosing the option with the most first preferences, it compares proposals pairwise. Option E was the sole member of the Schwartz set and beat every competing option in the relevant head-to-head comparisons, making it the unambiguous winner under Debian’s procedure.

Notably, E beat:

  • The “allow AI with conditions” option B, 203–148.
  • The cautious/avoid-where-practical option F, 210–130.
  • The “humans create Debian” direct-output prohibition G, 251–139.
  • The climate-focused avoidance option H, 244–154.
  • “None of the above,” 281–126.

Practical meaning

For a Debian maintainer or contributor, this is not a blanket approval of generated patches. It means AI assistance is allowed, but normal Debian expectations remain fully in force:

  1. You own the submission and must be able to explain and defend it.
  2. You must verify it technically and legally, including licensing and provenance.
  3. You must not leak private or security-sensitive project information to outside AI services.
  4. Automated or high-volume AI-derived changes still require normal project discussion and human oversight.
  5. Saying an AI helped is good etiquette, but the adopted resolution does not make it compulsory.

The resolution was discussed from July 23 through August 13, 2026, with voting held August 15–28. Of 1,045 eligible Debian Developers, 425 ballots were tallied.