DebOps LLM-Generated Contributions Policy

Date drafted

2026-07-02

Date effective

2026-09-01

Last changed

2026-07-02

Version

0.1.0

Authors

Large language models (LLMs) and AI-assisted coding tools have become a standard part of many developers' toolchains. The DebOps Project treats them like any other tool: what matters is not how you wrote something, but whether you understand it, can defend it, and take full responsibility for it.

These standards of quality and accountability have always applied to contributions. We are making them explicit now because AI tools make it trivially easy to generate plausible content without understanding it.

Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119].

Core Principle

There must be a human in the loop.

Anyone submitting code, documentation, or other content to the DebOps Project MUST review, understand, and be able to explain all content they submit, regardless of how it was produced. If you use AI tools to help write contributions, you are still the author and bear full responsibility for the work.

This means:

  • You have read and reviewed content before submitting it.

  • You, as a human, can answer questions about your work during review.

  • You have built and tested code contributions.

Submitting unreviewed AI-generated content wastes scarce maintainer time and is unacceptable. Contributions that lack thoughtfulness and care may be declined outright.

Contributors MUST review their work and not submit content they recognize as a verbatim copy of copyrighted sources. Contributors MUST apply the same license-compatibility diligence to AI-generated content as to any other third-party code. AI tool terms of service must not place restrictions on generated output that would conflict with the project's licensing or the ability to GPG-sign the resulting commits.

OpenPGP Signing

All commits that result from LLM-generated code SHOULD be signed by a valid OpenPGP key. This includes commits authored directly by a human using AI tools as well as commits made by AI-enabled forge accounts.

A valid OpenPGP key is one that has not expired, has not been revoked, and is discoverable on public keyservers or via Web Key Directory (WKD).

The signing key SHOULD be published on public keyservers (for example keyserver.ubuntu.com) and SHOULD be associated with the corresponding code forge account for easy verification.

This extends the existing DebOps Code Signing Policy, which already requires signed commits from DebOps Developers and recommends them for all contributors.

LLM Commit Trailer

Every commit that contains content generated in whole or in substantial part by an LLM MUST include the following Git trailer in the commit message:

Generated-By: LLM

A contribution is considered substantially generated by an LLM if more than 10 lines of the diff, or any single line of logically significant content (a conditional, a regex, a configuration value), was written by an LLM and accepted without structural modification.

The Generated-By value SHOULD be LLM. Contributors MAY append a model identifier in parentheses — for example Generated-By: LLM (Claude) — for additional transparency. Automated tooling SHOULD treat any value containing LLM as compliant.

This trailer lives in the Git metadata, not in file content. It is compatible with REUSE and SPDX file-level license and copyright headers — the trailer makes no statement about file-level licensing. It provides a machine-parseable record of provenance that automated tooling can use to evaluate compliance with this policy.

Maintainers MUST preserve the Generated-By: LLM trailer during merge. If a PR branch is squashed, the committer SHALL add the trailer to the resulting commit.

Commit Message Quality

All commit messages, regardless of how the code was produced, MUST follow the project's existing conventions:

  • Separate subject from body with a blank line.

  • Limit the subject line to 50 characters (hard limit 72).

  • Capitalize the subject line.

  • Do not end the subject line with a period.

  • Use imperative mood — "Add feature", not "Added feature".

  • Wrap the body at 72 characters.

  • Explain what and why, not how — the code shows how.

  • Keep each commit focused on a single logical concern.

Commit messages MAY be generated entirely by an LLM, provided a human reviews them for correctness and human-friendliness. The same quality standards apply as for human-written messages: the subject must fit the change, the body must explain the motivation, and there must be no AI-style boilerplate or verbose filler.

Pull Request Descriptions

Pull request descriptions MAY be authored by an LLM, provided a human reviews them before submission. The description must be human-friendly and follow the project's established format:

  • One or two paragraphs combining what the change does and why.

  • No section headers ("Summary", "Changes", "Why", etc.).

  • No bullet-point lists of changes (GitHub already shows the commit list).

  • No AI-agent boilerplate ("Here is a summary of the changes...").

  • Describe the change and its motivation in plain prose.

Prohibited Practices

The following practices are prohibited:

  • Unreviewed AI output. Submitting AI-generated content that the contributor has not reviewed or cannot explain.

  • Proxy submissions. Acting as a conduit between an LLM and the project without understanding or editorial judgment.

  • Unauthorized agents. Automated agents that take action in project spaces (opening issues, submitting PRs, posting comments) without explicit human approval for each action.

  • LLM-mediated review. Passing reviewer feedback or questions to an LLM and posting the AI-generated response without independent understanding or analysis. Reviewers expect to engage with a human who understands their own work.

  • AI-generated issue reports. Filing bug reports, feature requests, or security issues using LLM-generated content without human verification. Incorrect AI-generated security reports are particularly harmful because they waste maintainer time and desensitize maintainers to real issues.

Code review feedback that draws on LLM suggestions is subject to the same Core Principle: the reviewer must understand and stand behind the feedback they post.

Scope

This policy applies to all contributions to the DebOps Project, including but not limited to:

  • Code (pull requests; PRs)

  • Issues and bug reports

  • Comments and discussions

  • Code review feedback

  • Documentation

  • Proposals and DEPs (DebOps Enhancement Proposals)

This policy does not apply to:

  • AI-assisted language utilities: spelling and grammar checkers, translators, provided they do not generate novel content or restructure logic.

  • Authorized bots owned and operated by the DebOps Project (for example CI integrations, automated testing infrastructure).

Transition

Pull requests and issues opened before the effective date of this policy (2026-09-01) are not subject to its requirements. Contributors are encouraged — but not required — to apply the Generated-By: LLM trailer to subsequent commits on existing branches.

Handling Violations

Maintainers MAY close pull requests, close issues, and hide comments that they reasonably believe violate this policy. Before taking action on ambiguous cases, maintainers SHOULD ask the contributor for clarification and SHOULD cite a link to this policy. Contributors are welcome to ask clarifying questions, revise their work, and resubmit once they can demonstrate understanding of their contribution.

Repeated violations by the same contributor may result in a temporary or permanent ban from the project's spaces, handled according to the project's Code of Conduct enforcement guidelines.

Additional References