Clarifying a CNCF-Wide AI Contribution Policy for Projects?

[yada]

Context

At Microcks (https://github.com/microcks/microcks), we are currently discussing the introduction of AI-related checks and policies to help:

• avoid problematic or low-quality AI-generated contributions,
• reduce the review burden on maintainers and code owners,
• and provide clearer expectations to contributors using AI tools.

We’ve observed that many open source projects and organizations are moving in this direction.

Existing references

Some examples that illustrate different approaches:

• Ghostty project – a clear and fairly strict, but well-explained policy embedded directly in contribution workflows:
  https://github.com/ghostty-org/ghostty/pull/10412/files

• Linux Foundation (LFX) AI policy – currently quite light and high-level:
  https://www.linuxfoundation.org/legal/generative-ai

• OpenInfra Foundation AI policy – a more detailed and actively maintained policy that projects can directly rely on:
  https://openinfra.org/legal/ai-policy

We also see early signals of potential issues and confusion emerging across CNCF projects, for example:
#936

Question to the CNCF / TOC

Is the CNCF planning to:

1. Define and publish a CNCF-wide AI policy (similar in spirit to OpenInfra’s) that projects could directly reference?
   or
2. Recommend that each CNCF project define its own AI policy, tailored to its community, governance, and contribution model?

Microcks perspective

From the Microcks side, we would strongly welcome:

• a clear, CNCF-backed AI policy that projects can reference as a baseline, and
• the ability for projects to derive or “decline” their own project-specific version, similar to how we currently reference and adapt the CNCF Code of Conduct:
  https://github.com/microcks/microcks/blob/master/CODE_OF_CONDUCT.md

This would help ensure consistency across the ecosystem while still allowing flexibility for individual projects.

Goal of this issue

The goal of this issue is to:

• clarify the CNCF’s current thinking and direction on AI governance for projects,
• understand whether a CNCF-level initiative is planned or recommended,
• and, if relevant, discuss how projects can collaborate on a shared, well-defined AI policy rather than reinventing it independently.

Thanks for the guidance and discussion.

[caniszczyk]

The current AI contribution policy for CNCF is inherited by the LF as you mentioned:
https://www.linuxfoundation.org/legal/generative-ai (mostly from a legal pov)

Just like projects can define your own governance or contribution policy we expect the same for how they expect to work with AI contributions. Some projects may have more tolerance than others for specific tools.

We'd encourage contributions to https://contribute.cncf.io/projects/best-practices/templates/ for a template that a CNCF project can reuse.

[krook]

The CloundNativePG project has also drafted their own policy.

[yada]

The CloundNativePG project has also drafted their own policy.

Thanks for sharing @krook as it can clearly help projects IMHO to re-use and adapt based on their needs.
Let's keep this thread open so we can share and, maybe later, create a common baseline policy (template).

[xmulligan]

If it is help, we at Cilium are compiling a lot of different policies to help us understand where we finally want to fall cilium/community#239

[charlieegan3]

For OPA we have some evolving AI guidelines here: https://www.openpolicyagent.org/docs/contrib-code#ai-guidelines which references https://www.linuxfoundation.org/legal/generative-ai.

We had the first violation of "the one PR at a time" rule for new contributors this week, but generally people seem to be unaware of the rules. We are trying to be polite.

We use this config: https://github.com/open-policy-agent/opa/blob/main/.claude/settings.json to have claude read agents.md and the contribution guidelines at startup. But no data to show this is actually working. We have avoided putting in tool-specific files otherwise in the hope that there is some standard.

We have had significant issues with 'simple' docs PRs where the text is technical and takes a very long time to get right when the contributor has little expertise. In addition, since the content is generated it must be manually checked for things which have been made up (metric names etc), which takes a lot of time.

[tuminoid]

For Metal3-io, we have similar experiences as @charlieegan3 expressed. It is really painful to review those generated PRs, especially the ones that try to be helpful and include a lot of documentation.

We have thus made a decision that it harms us more than help to enable Copilot reviews for everybody, as then the AI is reviewing AI, and often goes completely in wrong direction, and makes everything a mess, and frustrates the contributor as well. We thus are requesting AI reviews only for those PRs that we know the contributor can handle and also are worth checking. This is again more mental load on maintainers etc etc.

Another aspect is the instruction file pollution. We have compromised and created AGENTS.md files, as it helps with Copilot review bot too, and symlinked it as CLAUDE.md, as Claude is the notorious example of not following AGENTS.md, to get reasonable coverage with just two files. It has improved the code reviews and also submissions somewhat, but it is far from perfect.

edit: We are also not comfortable enabling pure agent PRs, and hold all contributions to same standard regardless of what tools have been used. We feel that requiring that bit of information is not productive, as we as community have never cared if people have used vim or VScode or code intelligence completions to produce the code they do. The contributor must be able to sign DCO regardless, and pure agents cannot do that, but this surely is one of the major differences on how projects deal with the license/copyright/attribution aspects.

[yada]

I’m glad to see this topic resonating within the community, and thank you for sharing your details; they’re very valuable.
This isn’t an easy subject, but it clearly needs to be addressed to avoid greater pain down the road...
It could actually make for a great discussion at a future KubeCon Maintainer Summit 😉