Position on use of generative AI in contributions

[EstherPlomp]

Related to #4424

We are getting PRs in from new contributors, we suspect using generative AI, that are time consuming compared to the additions/quality they add to the book:

• Mostly or entirely superficial changes (whitespace, synonyms) which obfuscates any useful change
• Not engaging with book structure (for example, creating new files in nonsensical directories, not updating ToC)
• Apparently machine generated code (vague, hallucinatory text)
• Apparently machine generated PRs and comments (references to irrelevant or non-existent issues, disconnection between PR description and changes, spammy messages asking for reviews)
• Poor engagement (refusal to make changes, ignoring change requests or making unrelated changes)

To avoid the time sink to address this, it would be easier to prevent these PRs or have a reason to quickly close them by adding a text to the contributing.md such as:

"We're not saying you can't use generative AI, but it isn't reasonable to ask us to review entirely machine generated contributions or contributions which the author hasn't reviewed/edited"

• How do we formulate this in a clear/constructive manner?
• Should we be even more restrictive on generative AI?
• Thoughts?

[JimMadge]

I think the way data taken (usually without permission) from sources of many different licenses (some proprietary) presents a compliance problem for the output of generative AI models. At the very least, they fail to attribute or provide the license and copyright notice for works they substantially reproduce, which are common requirements of permissive licenses. I have to imagine this is worse for more restrictive licenses.

So, I would lean towards saying we don't accept contributions which are substantially created by or based on generative AI output.

I suspect I might be in the minority there. I think

"We're not saying you can't use generative AI, but it isn't reasonable to ask us to review entirely machine generated contributions or contributions which the author hasn't reviewed/edited"

might be a good balance.

[sgibson91]

I don't know how you would confirm that a contribution was definitely entirely AI written without also spending the same/similar amount of time to actually review it. So while I think it's noble, I don't think it's a practical solution. We just move the time sink.

[JimMadge]

Absolutely, you couldn't know for certain. And maybe it isn't really about determining "was AI used here" and more "has there been enough human in the loop here"?

I think part of reviewing is making decisions so it is more about using your best judgement.

[likeajumprope]

Absolutely, you couldn't know for certain. And maybe it isn't really about determining "was AI used here" and more "has there been enough human in the loop here"?

I think part of reviewing is making decisions so it is more about using your best judgement.

I agree actually. I don't think it's particularly wrong or bad if AI has been used if 1) a human has had a look at it 2) it was made transparent that AI has been used and for what parts of the PR. So the latter, a request for transparency, is also something that I would add.

[Arielle-Bennett]

I would be in favour of a stock response that provides some pathways forward and also aligns with our contributing guidlines, e.g.

We're not saying you can't use generative AI, but we suspect that this PR has been entirely machine generated without author review.
It is not reasonable to ask maintainers to review contributions or contributions which the author hasn't reviewed/edited first themselves.
Please review our contributing guidelines in relation to the suggested edits, and if you would like a review after that, please open a new PR which utilises the project's PR template.

Also note that I've just looked at our contributing guidelines and we don't actually state what PRs should have in them -_____- and that the contributing guidelines spend a lot of time on CoC etc up top, but do not reflect technical contribution requirements. So I'm adding an issue to fix that 😁

[JimMadge]

That might be covered by the PR template. But if we don't say that in the contribution guide we should 👍.

[EstherPlomp]

Agree with Jim to not accept PRs that are substantially written by AI - If in doubt we can check with the person if it is the case and if they don't respond close the PR? For now it is still quite clear what is AI generated and what is not, perhaps that will change in the future..

[LizHareDogs]

I think it's great that we're clarifying this. I like Arielle's idea which makes me think about what a good PR is., including things like being concise, specific, editing, proofreading, etc. After we talked about this Wednesday I wanted to look at whether someone has already created a guide for writing good PR's but I haven't gotten to it. We might need to do it ourselves to address the patterns Jim is seeing and has described so well.

[sayantikabanik]

Sharing my thoughts experiences from reviewing/contributing/maintaining to multiple Open-source project pre & post Gen AI arrival

The pain point IMO lies in:

- surface-level changes that don’t address the actual issue
- increased cognitive load on volunteer maintainers
- Slowing down of the project velocity

Flip side: Gen AI could still be an effective "tool"; The issue lies in undisclosed/unguided use!
(I am an optimist 😄)

How to mitigate (not 100%, but a decent start)

1. AI-use self-disclosure checklist in PR templates feels like a great start

- What percentage (approx) of the code was AI-generated?

2. Auto-labelling rule for “low-signal” PRs for visibility & quick dive

E.g.:
 - PRs with thousands of LOC changes on trivial issues
 - PRs without a linked issue

3. Introduce a “Reviewability Score” in the PR template (tricky to enforce, ties back to point 01 )

Contributors must self-score on:
- scope clarity/ readability/ justification
This pushes them to self-evaluate quality before hitting “create PR.”

4. Offer a short “AI-for-contributors” guideline page

 - How to avoid hallucinated APIs
 - How to write minimal diffs
 - Exploration and discussion with Gen AI 

5. Use CI linting to catch common Gen-AI relics

- repeated blocks
- AI-generated meta-data (Gen AI images have a clear label)
- hallucinated variables

[RichardJActon]

The Fedora community had a pretty lengthy discussion about AI contribution policy that resulted in a pretty pithy statement of their position that might be useful to take inspiration from: https://docs.fedoraproject.org/en-US/council/policy/ai-contribution-policy/

[JimMadge]

That seems like a balanced position; not preventing the use of AI tools but being proactive in addressing issues they could cause.

[g-adel]

Nice example of how one project addressed turning off submissions: tldraw/tldraw#7695

[JimMadge]

That is a good read. I think for us, automatically closing PRs from external contributors is a step too far (probably a good few steps too far). I can see that working for a project with a steeper onboarding ramp though.

The spirit feels very similar, we want to protect maintainer time and not spend it on poor quality contributions.

[g-adel]

Agreed! I was mainly referring to the tone and language used :D

[Arielle-Bennett]

Also adding that this LinkedIn post has a bunch of different examples from different open source projects - most of them are asking for transparency, and one project has added an agents.md to guide agentic AI on nudging people using those tools to follow contribution guidelines which might also be useful for us...

https://www.linkedin.com/posts/abbycabs_looking-for-examples-do-you-know-any-open-activity-7417759066770403328-tZ4C?

[JimMadge]

I spoke with some Zulip team members at FOSDEM about this (and managing contributions in general).

They have a use of AI section in their contributing guide

[EstherPlomp]

Resource dump: other people/project's AI policies overview: https://github.com/melissawm/open-source-ai-contribution-policies

[Arielle-Bennett]

Noting that we discussed this topic in the @the-turing-way/steering-committee meeting today - there's a lot of nuances here but what the SC members in attendance would like to do to move the discussion forward to a policy is either:
a) SC (and any interested people in this discussion) to draft an initial AI contribution policy to discuss at the Community Forum in June
OR
b) Hold a community discussion in June then task people (probably subset of SC and any interested people in this discussion) with drafting the policy to get approved

What would contributors to this discussion so far prefer as a path forward?

[Maryblessing]

Noting that we discussed this topic in the @the-turing-way/steering-committee meeting today - there's a lot of nuances here but what the SC members in attendance would like to do to move the discussion forward to a policy is either: a) SC (and any interested people in this discussion) to draft an initial AI contribution policy to discuss at the Community Forum in June OR b) Hold a community discussion in June then task people (probably subset of SC and any interested people in this discussion) with drafting the policy to get approved

What would contributors to this discussion so far prefer as a path forward?

I'm in favour of option b.

[JimMadge]

I would say a. I think it helps to have a draft to focus the discussion around.

[SaraVilla]

I'd also say B, or at least bringing clear discussion points to then be developed into a community draft after the community forum.

[SaranjeetKaur]

Dumping here some AI policies developed by different communities:

• https://ropensci.org/blog/2026/02/26/ropensci-ai-policy/
• https://www.pyopensci.org/blog/generative-ai-peer-review-policy.html
• https://joss.readthedocs.io/en/latest/policies.html#ai-usage-policy
• https://github.com/executablebooks/MyST-Parser/blob/master/AGENTS.md
• https://pharmaverse.github.io/blog/posts/2026-03-31-agents-md-admiral-a/agents-md-admiral-and-the-ai-assisted-programmer.html
• https://docs.kernel.org/process/coding-assistants.html
• https://llvm.org/docs/AIToolPolicy.html#details

[SaranjeetKaur]

I quite like that the LLVM project's AI use policy does not recommend using AI tools for fixing issues labelled good first issue. Hopefully, this can reduce a lot of slop.

AI tools must not be used to fix GitHub issues labelled good first issue. These issues are generally not urgent, and are intended to be learning opportunities for new contributors to get familiar with the codebase. Whether you are a newcomer or not, fully automating the process of fixing this issue squanders the learning opportunity and doesn’t add much value to the project. Using AI tools to fix issues labelled as “good first issues” is forbidden.

[JimMadge]

Reminds me of this debacle.

I do think it is important for our community that issues which are good entry points for new contributors are left for people to solve.

[sgibson91]

I'd recommend an AGENTS.md or something similar that codifies this sentiment, so that someone using a coding assistant won't do this anyway.

As usual, expect no one to read documentation.

[LizHareDogs]

Here is a new blog post on AI from the R consortium: https://r-consortium.org/posts/open-source-makes-ai-better/

[malvikasharan]

Draft developed with @Arielle-Bennett summarizing the notes here:

We have enough information here to start drafting:

• Maintain respect and care for the editors, reviewers, maintainers and readers of this book
  • This means filling all information requested in issue and PR
  • Add in our issue and PR template section to declare use of AI
  • Take care of the volume - don't unnecessarily write longer/multiple chapters if something can be said concisely in a short/single chapter
  • Be thoughtful and intentional about all contribution. Re-emphesize the effort needed to engage: https://book.the-turing-way.org/community-handbook/contributing/#ch-contributing-low-effort
• Never tackle/target an issue which are tagged "good first issue" - they are not for agents to solve - that's our way to let new contributors into the project
• We prefer drafts that people create by themselves - that is what The Turing Way is for.
• We recognize that people use AI and we want them to hold responsibility of transparency of where AI has been used, which AI was used and how. Provide prompts where necessary as a footnote or callout note
• Do not use LLM on files that are not being edited or reviewed (for example, changing multiple unrelated files when using AI)
• Review your content before sending it as a PR
• Some information we can adopt in The Turing Way:
  • https://en.wikipedia.org/wiki/Wikipedia:Artificial_intelligence
  • https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing
• We as Turing Way community will have to hold good standards of review
• Update our README and Contributing guidelines to make those simpler and move collaborating on GitHub on the top
• Section in the community handbook for guidance for authors - we can adapt rOpenSci/others guidance

---

Planning for the September Community Forum

• Allocate Collaboration Cafes to write our AI positioning
• Discuss this in September
• Use notes from Book Dash AI Discussion (@AlexandraAAJ)

Fireside Chat

• Why is it worth maintaining The Turing Way
• Psychological impact of AI-generated PR on maintainers
• Productivity vs Quality and burnout caused by AI