Hi devs,
Disclosure: this proposal was drafted with Claude Code, on my prompting, after reviewing our past forum discussions and the AI policies of about 25 other open source projects.
Why
We’ve already agreed on one AI rule, the Co-Authored-By attribution in commits (AI attributions in commits?), documented in Working with AI. But several questions are still open or not written down:
- AI disclosure in PRs and a general AI policy (18747), and AI on the forum (18746), both without a conclusion.
- What we said in those threads but never wrote down: the contributor is responsible for what they submit, and using AI can’t be mandatory.
- Low-effort contributions produced with AI, which many projects now receive, and AI-generated security reports (curl paused its reports in July 2026; Go, Keycloak and others now warn against them).
- Automated agents acting on our repositories: the Sonar routines, the
xwikiorg-llm-botPRs, the proposed daily xwiki-review, the OSS Scanner. - Confidential data (undisclosed security issues) sent to AI tools.
So I’m proposing a single AI Policy page on dev.xwiki.org (Community/AIPolicy) covering all of this. The full proposed text is at the end of this post.
The proposal in short
Scope: every way of contributing to the xwiki and xwiki-contrib projects (code, PRs, JIRA, security reports, forum, xwiki.org documentation, translations) and automated agents acting on them. Not about XWiki’s own AI features (LLM application, MCP server).
- Allowed, never mandatory. Use AI tools or don’t; it’s your choice.
- You are responsible for everything you submit, whatever tools helped, exactly as if you’d written it yourself: correctness, licensing, and follow-up in review and after merge.
- Low-effort contributions may be closed, with a standard reply, when the submitter clearly didn’t make them reviewable (doesn’t build, unrelated changes, ignores the template or the conventions, no engagement in review). This applies whether AI was used or not: nobody has to guess.
- Commit attribution: the
Co-Authored-Byrule stays as agreed. If it’s missing, the reviewer asks for it, like any other convention. - Disclosure elsewhere (PR text, JIRA, forum, docs) is encouraged, not required: if you’d credit a human who helped you that much, mention the AI. Spelling, grammar and translation help never needs a mention.
- Security reports made with AI: say so and how; include a proof of concept actually run on a supported XWiki version (by you or your tools); say what you couldn’t verify. Reports without such a PoC may be closed without detailed analysis. Programmes we’ve opted into (e.g. OSS Scanner) follow their own agreed terms.
- Confidential data (undisclosed security issues, private lists, users’ personal data) only goes to AI tools that don’t train on your inputs: a commercial plan (e.g. Claude Team, Enterprise or API, which aren’t used for training) or a personal plan with training turned off in its settings. This applies to reporters too. Never credentials.
- Licensing: the AI tool’s terms must not restrict the use of its output in a way incompatible with the LGPL, and no third-party material (including copied through the AI) unless its license is compatible and it’s credited.
- Automated agents have a named owner, are agreed on the forum before running on our repositories or channels, never merge nor push to
master/stable-*, are identifiable (xwikiorg-llm-botaccount,llm-agentlabel), and can be paused by any committer pending discussion. - Reviews and decisions: AI-assisted reviews are welcome and owned by whoever posts them. AI is never the sole basis for rejecting a contribution, and is never used to judge people (committership, roles, conduct).
What I deliberately don’t propose
Each of these exists elsewhere (see the survey below); I don’t think we need them now, but we can revisit them if a problem shows up:
- A ban (Gentoo, NetBSD, QEMU, Servo, Zig): contradicts what we agreed in 18703 and how most of us work.
- Describing the exact AI methodology in PRs (18747): costly for little value; the commit attribution already gives reviewers the signal.
- Banning AI-written forum posts (18746) or AI-written replies to reviewers (Kubernetes): we judge the content, not its origin, it helps non-native English speakers, and it can’t be detected reliably.
- Gates such as vouching for newcomers (Ghostty), caps on open PRs, or no AI on good first issues (LLVM, Mozilla): no flood so far.
- CC0 headers for mostly-generated files (Eclipse): legal theory we don’t need to settle.
- A tested fix with every AI-found security report (Linux kernel): too much to ask of outside researchers.
One known risk: the Linux kernel removed its Assisted-by trailer on 2026-10-13, because only ~10% of commits carried it while AI use was far more widespread, so its absence said nothing. Our situation is different (most of our AI-assisted commits come from committers whose tooling adds it automatically), but we should check after some time whether our trailer still gives a useful signal.
What it would imply
- Create
Community/AIPolicywith the text below. - Reduce the “Working with AI” section of DevelopmentPractices to a pointer to it, plus “Recommended tooling” and “Attribution in commits”.
- Add pointers from Contributing, the Security Policy (and the vulnerability report form, if we move to GHSA reporting) and the forum guidelines.
- Make the xwiki-dev-llm plugin point to the page instead of restating it.
- Conclude 18746 and 18747 with a link to this topic.
Unless there are objections, I’ll consider this agreed by lazy consensus; if a specific point is contested, we can vote on that point.
WDYT?
What other projects do (survey, October 2026)
Sources read on 2026-10-29. Positions summarised; see each policy for the exact wording.
| Project | Stance | Disclosure | Notable rules |
|---|---|---|---|
| Linux Foundation | Allowed with conditions | — | The two licensing conditions we reuse (tool terms compatible with the OSS license, no third-party material without permission) |
| Linux kernel | Allowed with conditions | Assisted-by trailer removed on 2026-10-13; free text in the cover letter |
AI-found bugs need a reproducer and a tested fix; no agent may send anything itself |
| ASF | Allowed with conditions | Generated-by: / Co-authored-by: token recommended |
Tool terms must grant enough rights; no third-party material unless compatible |
| Eclipse | Allowed with conditions | Assisted-by if you’d credit a human |
No bot pushes without human review; CC0 header for mostly-generated files; no confidential info in tools |
| OpenInfra | Allowed with conditions | Assisted-By recommended |
Autonomous submissions refused because no human is accountable, not because a tool was used |
| Fedora | Allowed with conditions | Required when output is used unchanged | AI never the sole arbiter on a contribution, never used to judge people |
| LLVM | Allowed with conditions | Assisted-by |
“Extractive contributions”: a contribution must be worth more than its review time; no agents acting without human approval; no AI on good first issues |
| Kubernetes | Allowed with conditions | In the PR description; trailers forbidden (CLA) | Replies to reviewers without AI; PR closed if you can’t explain it |
| Ghostty | Allowed with conditions | Required | Newcomers must be vouched for |
| CPython | Allowed, same rules as anything | Encouraged | Labels plus a bot comment to close policy violations |
| Mozilla | Allowed, same rules as anything | — | No embargoed security details in third-party AI tools |
| Debian | Allowed (2026 vote, ban option defeated) | Encouraged | — |
| curl | Allowed with conditions | Required for security reports | Ended its bug bounty, paused security reports in July 2026; fake reporters banned |
| Rust | Analysis and review only | Required | “Style is not evidence”; pauses AI-created PRs if they exceed 50% of merges |
| GCC | Restricted (no legally significant AI content) | Assisted-by required |
Test cases exempt; no LLM commits |
| QEMU, NetBSD, Gentoo, Servo, Zig | Banned | — | Mostly based on DCO/provenance (QEMU, NetBSD) or on review burden and ethics |
Trends: disclosure is moving from commit trailers to free text; the focus has moved from code to communication (issues, review replies) and security reports; enforcement relies on quality rules and gates rather than on detecting AI.
Proposed text of the Community/AIPolicy page
AI Policy
This policy applies to everyone contributing to the XWiki projects (the xwiki and xwiki-contrib GitHub organizations): code, pull requests, JIRA issues, security reports, forum posts, documentation on xwiki.org and translations. It also applies to automated agents acting on these projects. It’s not about the AI features of XWiki itself.
Principles
- Using AI tools is allowed, and never mandatory. Whether and how you use them is your choice.
- You are responsible for everything you submit, whatever tools helped you produce it, exactly as if you had written it yourself: its correctness, its licensing, and the follow-up in review and after merge.
Contributions
Attribution in commits
When an AI tool helped write a commit, add a Co-Authored-By trailer, as described in Attribution in commits. When it’s missing, the reviewer asks for it to be added, as for any other convention.
Disclosure elsewhere
Mentioning the use of AI in a pull request description, a JIRA issue, a forum post or a documentation page is encouraged but not required. Rule of thumb: if you would credit a human who helped you that much, mention the AI. Help with spelling, grammar or translation never needs a mention. Security reports have their own rule (see below).
Licensing
- The terms of the AI tool must not restrict the use of its output in a way incompatible with the LGPL.
- A contribution must not include third-party material (including material reproduced by the AI tool), unless its license is compatible and it’s credited as for any third-party code.
We follow the evolution of the law and of the guidance of other open source foundations, and will update this section accordingly.
Low-effort contributions
A contribution should be worth more to the project than the time it takes to review it. A committer may close a contribution without a detailed review when it’s clear that the submitter didn’t do the work needed to make it reviewable, for example when it doesn’t build, contains unrelated changes, ignores the pull request template or the conventions, duplicates an existing one, or when the submitter doesn’t engage in the review. This applies whether AI tools were used or not: there’s no need to guess.
Standard reply:
Thanks for your contribution. We’re closing it because it isn’t in a state we can review: <reason>. See our AI Policy; this applies whether or not AI tools were used. You’re welcome to submit a new one once this is addressed.
Security reports
If you used AI tools to find or write a security report:
- Say so in the report, and how they were used (finding the issue, writing the report, or both).
- Include a proof of concept that was actually run against a supported XWiki version, with the steps to reproduce it. You or your tools may have run it; you’re responsible for it. Describe the impact following the Security Policy.
- Say what you couldn’t verify.
- Use an AI tool that doesn’t train on your inputs (see “Confidential data” below): an undisclosed vulnerability is confidential.
Reports without such a proof of concept may be closed without a detailed analysis, and repeated ones may lead to the reporter being blocked. Scanning programmes the project has opted into follow the terms agreed for them.
Confidential data
Confidential data (undisclosed security issues, content of private mailing lists and forum categories, personal data of users) must only be given to AI tools that don’t use your inputs for training: a commercial plan (for example, the Claude Team, Enterprise and API offers aren’t used for training) or a personal plan with training turned off in its settings. Check the setting of your plan. This applies to committers and reporters alike. Never give credentials to an AI tool.
Automated agents
An automated agent is an AI tool acting on the project without a human triggering each action (scheduled routines, review bots, scanners). Each one:
- has a named owner (a person or a team), who answers for what it does;
- is agreed on the forum before it runs on the project’s repositories or channels;
- never merges, and never pushes to
masterorstable-*branches: a human reviews and merges what it proposes; - is identifiable: its pull requests come from the dedicated
xwikiorg-llm-botaccount and carry thellm-agentlabel; - can be paused at any time by its owner, or at the request of any committer pending a discussion.
Reviews and project decisions
- AI-assisted reviews are welcome. The person who posts a review comment owns it.
- AI is never the sole basis for rejecting a contribution: a human makes that decision and can explain it.
- AI is never used to judge people (committership, roles, conduct).
Thanks
-Vincent