Proposed guidelines for AI contribution

Referenced in their AI Policy is the Copilot instructions file which has specific items.

If you are an AI agent (GitHub Copilot, CodeRabbit, etc.) reviewing a PR for Kornia

This should be banned by default on Drupal gitlab in my opinion, it is even harder to deal with than AI generated issues and MRs because it disrupts existing work. The Kornia policy makes it sound like it's just allowed. It would significantly negatively impact core development if this started happening.

Some of the rest of it seems fine, but it all assumes single-author PRs, which is not what we have on gitlab. If a single person creates an issue and MR, and that MR is unreviewed LLM output, then it's easy to close that, but it's much less easy to do that if someone starts adding code to an existing MR or issue, and this for me needs significantly stricter rules because it can lead to destroying other people's work (at least without recourse to git reflog). We have in the past banned accounts on d.o for mass closing/won't fixing issues and other behaviour that was defacement rather than contribution.

Yeah I agree, dropping point 3 makes sense of the Kornia guideline.

I am with catch on this one.

The issue summary states "We have a very minimal set of initial policies, but we really need a more robust set of policies.". Can you explain the gaps in the existing policy?

Well, I'd think we keep it and explicitly say that it is not accepted in this project.

We also typically have more collaborative MRs in Drupal along with longer running issues, so we might want to address how to disclose over time or for collaborators. I think a section in the Issue Summary makes sense.

Thanks for raising this - I appreciate the intent behind trying to update policies for AI-assisted contributions.

However, I want to offer a different perspective:

In practice, it doesn’t make sense to enforce a rule that attempts to distinguish code written “with AI” vs without AI because:
• Today and in the future, the majority of code - including most professional contributions - will be written with the help of AI tools. AI suggestions are becoming a standard part of developers’ workflows, whether it’s Copilot, ChatGPT, code assist in editors, or other tools.
• There is no reliable way to prove if AI was used in a submission or not. You cannot enforce something that can’t be verified.
• From a maintainer and reviewer standpoint, what actually matters is the quality, correctness, and maintainability of the code — not how it was generated. Whether suggested by an AI or typed manually, the contribution should be evaluated by the same technical standards.

So instead of trying to police AI usage, we should focus on:
• Clear expectations about quality and testing (e.g., tests must pass, behavior must be explained, implementation should follow Drupal standards).
• Encouraging transparency and honesty, but without requiring labels that can’t be enforced meaningfully.
• Emphasizing human responsibility for all code submitted. The contributor is accountable for what goes in — regardless of tools used.

AI assistance is a tool, just like autocomplete, linters, or search engines, and it should be treated accordingly. The community benefit comes from good code and collaboration - not from drawing arbitrary lines around “AI vs non-AI.”

• From a maintainer and reviewer standpoint, what actually matters is the quality, correctness, and maintainability of the code — not how it was generated. Whether suggested by an AI or typed manually, the contribution should be evaluated by the same technical standards.

This leaves out that maintainers and reviewers have to review code to know whether it's correct, maintainable, meets quality standards etc. (yes some quality standards are automated, but you still end up looking at the results to see why the build failed etc.)

LLM code generation allows people to produce thousands of lines of code very quickly. On Drupal.org there have been multiple examples of people posting multiple-thousand-line MRs that they did not review themselves, which then took time from reviewers and maintainers - even just explaining why this was not an acceptable way to 'contribute' but in some cases actually trying to review those MRs. If necessary I can link to those examples, either in here or in slack.

We can have guidelines like 'Never post massive MRs that you have not reviewed yourself' if people really want to avoid saying the word 'AI', but it's not 'just another tool'. Obviously there are other ways to bulk generate code changes, some of which are good, but they tend to be either very targeted or very obvious.

We should not have rules that boil down to 'don't post bad code', because that can be incredibly discouraging to new, human, contributors who are trying hard to fix things, but are not expert Drupal developers.

An argument for disclosing AI-generated code could be the recent MongoBleed vulnerability, where:

[...] leaked memory can contain residual data from previous requests, potentially exposing highly sensitive artifacts such as cleartext credentials, authentication keys, session tokens, or personally identifiable information (PII) that the database recently handled.
[...]
Attackers do not need valid credentials or prior access to the system, expanding the potential attack surface.

From https://www.esecurityplanet.com/threats/87k-mongodb-instances-exposed-by...

See also MongoDB is F***ed for more view points, and perspectives as related to generating large amounts of code with AI. A single and small -- but dangerous -- piece of code can get missed by both the vibe coder, but also by the code reviewer on drupal.org, and slip into production.

In fact, even using IDE's with automatic code completion could be viewed as semi-AI'ish and considered included under a disclosure-rule, since they may also suggest dangerous code. But that's probably another discussion.

@hestenet, thanks. One more question. Is the idea to create an independent AI policy statement that is then linked as needed in places like the issue etiquette guidelines?

I read the Kornia policy and considered each point with out current practice and what is in "Abuse of the Contribution Credit system". I think our current documentation such as Core Gates and Policy cover the intention of the Kornia policy. The Drupal language style is generally 'softer' but we do use 'require' to say that disclosure is necessary. Therefore, I don't see the need for to the abuse policy or the 'issue etiquette' page.

What we don't have is an item in the issue template for AI disclosure. That could be added but we then have to train people to use it when they use AI. I can think of lots of scenarios where that would be difficult and messy. It is a nice idea and maybe someone can come up with a simple way for a contributor to tick a box or some such to make it easy.

The other idea was that in the "Abuse of the Contribution Credit system" the item about AI could be moved to the top of the list. It is, after all, the current 'hot topic'.

However, in Slack cmlara mentioned the Drupal TOS. Searching the TOS I see no reference to AI. That is where I think a change should be made. The use of AI should be there, covering all of d.o.

Another open source project has posted a comprehensive AI policy that I think makes some good points that we could borrow: https://jellyfin.org/docs/general/contributing/llm-policies/

That Jellyfin policy looks decent indeed, you can feel the pain experienced that informed each bullet point.

Another example of policy is https://llvm.org/docs/AIToolPolicy.html and it much shorter

Personally I see the problem in absence of guidelines for LLMs so vibe-contributors produce unpredictable code and it's really hard to onboard new people as they have to find, read and understand all this policies we have for ages. That's primary bottleneck ATM

Initial stub on it this guidelines now closed for "personal fear of addiction" reasons so not clear how to attract new contributors and stop spam MRs now.

Making new policy "somewhere in docs" is useless until community will decide what it wants in viable future - fight using policies and waste limited human resources to close MRs or have clear guidelines how to do that properly.

PS: the take about contibutors will not learn is false as there's no guidelines what newcomers need to know or learn (and how to do that)... instead LLMs can give a drupal-ladder and teach people

There's a much, much simpler way of doing this.

1. Add https://github.com/lobsters/lobsters/blob/main/AGENTS.md
2. Announce that in line with the values and principles of the Drupal project, fascist technologies are resisted and as such all contributions made using those including LLMs are refused.

I think the title is misleading , it is in fact a favorite tactic of promptfondlers: it should read "Proposed guidelines for LLM contributions". Before the emerge of this blight there were very useful ML tools including machine translation which can be useful for contributing and I doubt anyone has a problem with that. Mixing the successes of these tools allows LLMs to be painted in a much better light.

The current problem is AI is destroying open source, and it's not even good yet which led me to file a core issue to Ban LLM contributions. Indeed that's what should happen and the Drupal project should be loud about that. What else is left? When a prompt monkey makes a webapp it comes out in TypeScript + React + Next.js + Tailwind as some sort of default. They sure won't become Drupal contributors. Thus I suggest to try to collect those who shun these.

x-post for visibility: #3570498-32: AI tools for contributors and maintainers

In particular:

Over the years, there have been a great many things I disagree with Larry Garfield about, but his recent blog post is completely spot-on:

https://www.garfieldtech.com/blog/selfish-ai

I propose tweaking point #4 in comment #21 for timeframe and means of disclosure. Something like:

4. You must disclose whenever you have used AI. This disclosure must be made as a comment in the issue when you submit the content.

You must fully understand the issue and the most recent comments before trying to use AI to solve it. If you don't understand it, you will probably give a bad prompt and wind up posting a bad solution that only annoys the maintainers.

I am not sure this is mutually-exclusive from contributing in general. We want to encourage every contributor, by example, to read the issue summary, and encourage contributors to document and comment when they are confused by an issue summary or comment thread as that might stall the issue anyway.

You must disclose whenever you have used AI.

A good example for this is also good contribution, and is something that I need to work on myself. Before I start working on an issue, I should write a comment that I am going to work on the issue and how I am going to work on it. Often times we forget this step.

You must review and understand the output of the AI and test it yourself!
Please review this blog: https://dri.es/never-submit-code-you-do-not-understand

You must fix any problems with the AI-generated code before posting it to an issue.

I think these two are related and/or could be combined. As part of our contribution, we want to review, understand, and fix any problems with AI-generated code before posting it to an issue.

+1 to including examples.

Most important - you must be a good listener and collaborator with the project maintainer, original issue reporter, and other contributors on the issue. A 'drive-by' contribution where you don't follow up on feedback, or ignore previous discussion on the issue will likely result in an account ban.

This seems a bit one-sided. I think we all must be good listeners and collaborators, regardless of the tools we use or choose not to use. Being aware and respectful that someone may need to use a tool to collect their thoughts and/or help draft their thoughts from their native language into English is important.

Drive-by contribution should be discouraged in all cases, not just AI, and this falls under abuse of the credit/recognition system too.

I think rather than calling out that most of this as behavior specific to AI we should change it as a reminder of what is encouraged. What about something like this?

Contributing to Drupal with the use of generative AI is no different than when contributing without the use of generative AI. We expect you to

- Understand the proposed changes, and ask for help in public channels as that increases the chance of someone who knows being able to help out.
- Disclose what tools we used in our code reviews, merge requests, and testing such as how we used generative AI.
- Engage with contributors on the issue to come to a consensus on a proposed resolution rather than "drive-by contribution", which disrespects other contributors.
- Avoid being in a self-feedback loop either in our own bubble or in an AI bubble.

I personally find #21 a very good start.

I would just remove the mention to chatGPT (a brand) and find a general name for it: coding assistant using generative AI?

There is no doubt that using generative AI coding assistants can be powerful ways to jumpstart code or content.

- Engage with contributors on the issue to come to a consensus on a proposed resolution rather than "drive-by contribution", which disrespects other contributors.

Sometimes this is true sometimes it's not.

If I find a bug in a contrib module on a client project, then I might post an issue + MR with a fix, or find an existing issue and make or update an MR etc. But it's often the case that then three months go past without any further updates, then I stop working on the project, and by the time someone gets to the issue/MR to review, I'm not using that contrib module on any projects any more. With the time scales involved it's not really 'drive by' but equally it's definitely not continuing to engage with an issue to completion. Drupal.org issue fork workflow also allows people to make a small contribution to an issue, then disappear, without MRs getting stuck because the 'owner' is awol, so as long as the individual changes are constructive it can be fine for people to dip into an issue once.

On the other hand, there are issues where I really wish a particular contributor would stop engaging altogether, especially since their responses appear to be (undisclosed in this case, but would disclosure have made it better?) LLM output, for example #3491129: Drupal Core strategy for 2025-2028, developer consultation / #3508715: [policy, no-patch] EoL for majors six months after the release of the second subsequent major.

Sometimes this is true sometimes it's not.

Agreed. The quality of contribution matters including issue summary, comments, and code. But to me, low engagement is not writing a good comment or issue summary to explain what we’re working on and not introducing sweeping changes without collaboration e.g. the txt -> md changes situation. High engagement means that I pay attention to standards and etiquette in the community, which is shown by writing a good issue summary, explaining my methodology in a comment or review, and/or publishing a merge request after I work out the kinks.

My terminology is sometimes out-of-whack, and so maybe there is a better term for this to use than either engagement or drive-by contribution.

If someone did find a bug in a module, researched it, created an issue with steps to reproduce, created a merge request with code using generative AI, and wrote a comment disclosing the tools they used, then this is not any different than someone who does the same and writes a comment detailing different tools and knowledge they used. Although I think the latter more ethical and is a better way to learn Drupal.

And we try to lead by example, but maybe we are also not providing good enough examples. I blame myself for this. We try to remind new contributors to be specific about how and what they are doing on an issue by writing a comment, but sometimes they do not, and we have to provide feedback. Regardless of the tools someone uses, our comments should be detailed, but not overly verbose, and sometimes when we do not, we may unnecessarily cause stress on those who provide feedback so that we can improve.

It seemed worth posting something from the Core Contribution Mentoring Working Group, of which I am a member, alongside Chris Darke and mradcliffe. We have a key role in influencing the approach many first time contributors take in the project.
Our approach is currently to ensure that first time contributors consider the inherent risks involved in using LLM-based tools for creating code and make sure that anyone reviewing that code is aware that such tools have been used, usually through an issue comment. As Dries says, every contributor should “never submit code [they] don't understand”. maybe in future First Time Contributor Workshops, we can add in Dries’ quote.
Quite how any contributor “proves” they understand the code they submit is an interesting question. Maybe by adding an issue comment and describing its overall flow? Mind you, you could equally say this is necessary with code generated by many different tools, like drush gen or Module Builder.
To be honest, bringing people in through the contribution door is hard - if a tool allows us to increase the number of people who stay for Contribution Day by 1%, great. If those tools allow 1% of those to become regular core contributors, fantastic. If the tools then enable 1% of those new regular core contributors become the next key core maintainer, famdabbydozey!
Finally, the moral question is moot. Drupal, as an open source tool, is used for good and bad. So many good examples like the UN, Olympics, etc etc alongside so many bad examples. For example, I personally used it to market OxyContin. We would be uncomfortable if LLM-based tools were  required to contribute to the project but they are not and there are no plans to do so.

Not sure if this is exactly the right place to put this, but FWIW, here's where the Kubernetes project landed with this: https://www.kubernetes.dev/docs/guide/pull-requests/#ai-guidance

Using AI tools to help write your PR is acceptable, but as the author, you are responsible for understanding every change. If you used AI tools in preparing your PR, you must disclose this in the description of your PR. Listing AI tooling as a co-author, co-signing commits using an AI tool, or using the assisted-by, co-developed or similar commit trailer is not allowed.

A little bit more colour on the "why" behind this change from Kat Cosgrove.

This seems pretty sensible to me. It acknowledges that LLM code contributions are a preferred way of working for many developers. It echoes Dries's Never submit code you don't understand philosophy. And blocking the use of co-signing commits helps to address some of the thorny legal concerns, since it shifts responsibility for the code back on the contributor. (Who, of course, could be an AI agent themselves, but you gotta start somewhere. :P)

As webchick outlines in 28, Kubernetes have a clear and concise guideline – and one I know I can be happy with.

The thing that is different for us vs. Kubernetes and most github-based projects is this bit:

"..and if you cannot explain why a change was made, the PR will be closed.

When responding to review comments, you must do so without relying on AI tools. Reviewers want to engage directly with you, not with generated responses. If you do not engage directly with reviewers, the PR will be closed."

If an issue and MR is opened by someone who behaves like this, then we can close that specific issue. But so far this is not the common case.

What's more common is someone does it on an existing issue that someone else has opened. We can't just close the issue without rejecting genuine work done by other people. A lot of the 'feed the issue into an LLM and post the unedited output' type behaviour has been on existing issues including commits to MRs that were already in progress.

We can try to ignore comments, and rollback commits but the only tools we have in those situations are:

- 'tell people off and hope they stop'

- 'tell employers off if we think the behaviour is the result of directed credit farming'

- 'ask the da/site moderators to ban the account' and

- 'de-list the company from the marketplace'.

Variations of these ended up getting applied when people were posting screenshots of them applying patches in a very liberal interpretation of the contribution guidelines that adding screenshots to an issue was valid for issue credit a couple of years ago (obviously to show ux issues not that git apply works). That behaviour eventually slowed down but it was a losing battle for a while before it. LLM output is generally a lot more plausible and verbose than a screenshot of a patch applying and there is more plausible deniability about the behaviour.

So on d.o (and equally on gitlab issues) we will often not have the option of closing an issue, but instead there will either be no consequences except social opprobrium, or a ban hammer, with very little in-between.

The implications for disruption of existing issues are also higher and while the frequency of this is still low on d.o I'm already seeing that happen - someone wades in with non-sequitor comments and/or commits and kills the issue because it's a lot of effort to roll those back in order to then go forwards again.

I'm also adding how the Linux Kernel deals with AI contributions.

They include the Licencing issue which basically falls back under the code contributor.

It looks like the remaining concern is about copyright. As I read the policy, it is sufficient. So, I think this can be RTBC.

But maybe someone has a suggestion for improving the section about copyright?

@hestenet, thanks for the issue summary update.

I support adding 'contributions must be compatible with the GPL, including all relevant copyright regulations and restrictions in your jurisdiction' to this as a best effort for now. I am changing the status to needs work to add this suggestion. It just seems to emphasize that point, it is not a change of our intention.

And I think a new issue for legal advise in the Drupal Licensing Working Group project makes sense.