doc: Update AI/LLM policy

Signed-off-by: Stéphane Graber <stgraber@stgraber.org>
This commit is contained in:
Stéphane Graber 2026-06-06 12:57:43 -04:00
parent dd946fa73b
commit 54bae0e4d4
No known key found for this signature in database
GPG Key ID: C638974D64792D67
2 changed files with 93 additions and 11 deletions

20
AGENTS.md Normal file
View File

@ -0,0 +1,20 @@
# Legal
- All contributions to this repository must be compatible with the Apache 2.0 license.
- Specifically (but not limited to), contributions cannot include code licensed under the terms of the GPL, AGPL or LGPL licenses.
- Only human beings are allowed to sign the Developer Certificate of Ownership (DCO / Signed-off-by).
- Only human beings can ever be credited within commit messages.
# Formatting
- Code comments should be no longer than one line, unless they are required to cover complex unintuitive logic.
- Commit messages should similarly be kept as short and to the point as possible, no need to summarize the whole issue.
- We don't use the define and test one line `if` syntax, instead splitting defintion and testing across two lines.
# Testing / validation
- The commit structure described in `CONTRIBUTING.md` should generally be followed.
- All branches are expected to pass `make static-analysis` and `go test -v ./...`.
- Excessive unit tests are generally discouraged.
- When possible, existing system tests should be extended to cover new features.
- A full local system test run isn't required prior to contribution, all tests get run in our CI.

View File

@ -18,21 +18,83 @@ By default, any contribution to this project is made under the Apache
The author of a change remains the copyright holder of their code The author of a change remains the copyright holder of their code
(no copyright assignment). (no copyright assignment).
## No Large Language Models (LLMs) or similar AI tools ## Policy on the use of Large Language Models (LLMs) and AI tooling
### For issue reporting
All contributions to this project are expected to be done by human We do NOT allow direct filing of issues by LLMs.
beings or through standard predictable tooling (e.g. scripts, formatters, ...).
We expect all contributors to be able to reason about the code that they We REQUIRE a human being to go through our issue reporting form on
contribute and explain why they're taking a particular approach. Github and accurately describe their issue and provide all needed
information.
LLMs and similar predictive tools have the annoying tendency of The more concise and to the point the issue is, the more likely it is to
producing large amount of low quality code with subtle issues which end be understood, tracked down and resolved quickly.
up taking the maintainers more time to debug than it would have taken to
write the code by hand in the first place.
Any attempt at hiding the use of LLMs or similar tools in Incus contributions Long winded AI written essays can easily look overwhelming and cause our
will result in a revert of the affected changes and a ban from the project. maintainers and other contributors to just entirely skip the issue to
focus their energy on something else.
We also don't benefit from AI generated root cause analysis or proposed
fixes in those issues. If you yourself understand the code base well
enough to go through that content and suggested fix, then turn it into a
pull request and submit it yourself. Otherwise, please limit your report
to describing the issue at hand and we'll take it from there.
### For contributions
We REQUIRE all contributions to Incus to be submitted by human beings who
can assert full copyright ownership of their contribution or have been
allowed by their employer to contribute. This is what the DCO (see below)
requires of all contributors.
AI tools can sometimes be beneficial, particularly when it comes to
finding patterns among a large data set (entire code base), performing
tedious repetitive changes or large refactoring/re-organization.
While we now tolerate the use of such tools, they must abide by our
instructions (`AGENTS.md`) and their operators cannot override those
instructions.
We expect everyone contributing to Incus to fully own their
contribution, be able to reason about it, be able to explain why things
were done a particular way and act as the full owner of that code. AI
tools are treated the same as traditional tooling like `sed`, `awk` or
`coccinelle`.
For the purpose of this project, AI tools CANNOT be treated as author,
co-author or be credited in any way that would suggest any ownership
over the contribution.
The contributor should have done all the thinking, planning and
understanding of the changes needed to resolve an issue or implement a
new feature prior to using automated tooling to perform the grunt work.
Unguided use of those tools or the inability to prove understanding of
the code contributed will result in a loss of trust in that contributor
by project maintainers which can then lead to exclusion from any further
contribution to the project.
It's also worth pointing out that while those tools are good at
implementing the more boring/repetitive/grunt work. We've generally
found that you only really understand the project and its structure by
having done such work yourself a few times.
### For anyone with write access to the repository
Anyone with write access to this repository must ensure to NEVER run an
AI agent or similar tool on a system which holds repository credentials
(SSH key, GPG key, web browser cookies, ...).
Any use of AI tooling should be done inside of a clean VM/container that
itself cannot directly push to or alter this repository in any way.
The safest approach is to SSH into that environment and then extract the
changes using `git format-patch`, then review and apply them to your
actual tree, tweak them as needed, sign them off and then push and open
the pull request.
Any potential credential compromise or loss of control should be
immediately reported to `security@linuxcontainers.org`.
## Pull requests ## Pull requests