From 772edebca89bb597b33fafacbf6779944831718c Mon Sep 17 00:00:00 2001 From: jyn Date: Fri, 17 Apr 2026 08:58:02 +0200 Subject: [PATCH 01/12] Add an LLM policy for `rust-lang/rust` ## Summary [summary]: #summary This document establishes a policy for how LLMs can be used when contributing to `rust-lang/rust`. Subtrees, submodules, and dependencies from crates.io are not in scope. Other repositories in the `rust-lang` organization are not in scope. This policy is intended to live in [Forge](https://forge.rust-lang.org/) as a living document, not as a dead RFC. It will be linked from `CONTRIBUTING.md` in rust-lang/rust as well as from the rustc- and std-dev-guides. ## Moderation guidelines This PR is preceded by [an enormous amount of discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/588130-project-llm-policy). Almost every conceivable angle has been discussed to death; there have been upwards of 3000 messages, not even counting discussion on GitHub. We initially doubted whether we could reach consensus at all. Therefore, we ask to bound the scope of this PR specifically to the policy itself. In particular, we mark several topics as out of scope below. We still consider these topics to be important, we simply do not believe this is the right place to discuss them. No comment on this PR may mention the following topics: - Long-term social or economic impact of LLMs - The environmental impact of LLMs - Anything to do with the copyright status of LLM output - Moral judgements about people who use LLMs We have asked the moderation team to help us enforce these rules. ## Feedback guidelines We are aware that parts of this policy will make some people very unhappy. As you are reading, we ask you to consider the following. - Can you think of a *concrete* improvement to the policy that addresses your concern? Consider: - Whether your change will make the policy harder to moderate - Whether your change will make it harder to come to a consensus - Does your concern need to be addressed before merging or can it be addressed in a follow-up? - Keep in mind the cost of *not* creating a policy. ### If your concern is for yourself or for your team - What are the *specific* parts of your workflow that will be disrupted? - In particular we are *only* interested in workflows involving `rust-lang/rust`. Other repositories are not affected by this policy and are therefore not in scope. - Can you live with the disruption? Is it worth blocking the policy over? --- Previous versions of this document were discussed on Zulip, and we have made edits in responses to suggestions there. ## Motivation [motivation]: #motivation - Many people find LLM-generated code and writing deeply unpleasant to read or review. - Many people find LLMs to be a significant aid to learning and discovery. - `rust-lang/rust` is currently dealing with a deluge of low-effort "slop" PRs primarily authored by LLMs. - Having *a* policy makes these easier to moderate, without having to take every single instance on a case-by-case basis. This policy is *not* intended as a debate over whether LLMs are a good or bad idea, nor over the long-term impact of LLMs. It is only intended to set out the future policy of `rust-lang/rust` itself. ## Drawbacks [drawbacks]: #drawbacks - This bans some valid usages of LLMs. We intentionally err on the side of banning too much rather than too little in order to make the policy easy to understand and moderate. - This intentionally does not address the moral, social, and environmental impacts of LLMs. These topics have been extensively discussed on Zulip without reaching consensus, but this policy is relevant regardless of the outcome of these discussions. - This intentionally does not attempt to set a project-wide policy. We have attempted to come to a consensus for upwards of a month without significant process. We are cutting our losses so we can have *something* rather than adhoc moderation decisions. - This intentionally does not apply to subtrees of rust-lang/rust. We don't have the same moderation issues there, so we don't have time pressure to set a policy in the same way. ## Rationale and alternatives [rationale-and-alternatives]: #rationale-and-alternatives - We could create a project-wide policy, rather than scoping it to `rust-lang/rust`. This has the advantage that everyone knows what the policy is everywhere, and that it's easy to make things part of the mono-repo at a later date. It has the disadvantage that we think it is nigh-impossible to get everyone to agree. There are also reasons for teams to have different policies; for example, the standard for correctness is much higher within the compiler than within Clippy. - We could have a more strict policy that removes the [threshold of originality](https://fsfe.org/news/2025/news-20250515-01.en.html) condition. This has the advantage that our policy becomes easier to moderate and understand. It has the disadvantage that it becomes easy for people to intend to follow the policy, but be put in a position where their only choices are to either discard the PR altogether, rewrite it from scratch, or tell "white lies" about whether an LLM was involved. - We could have a more strict policy that bans LLMs altogether. It seems unlikely we will be able to agree on this, and we believe attempting it will cause many people to leave the project. ## Prior art [prior-art]: #prior-art This prior art section is taken almost entirely from [Jane Lusby's summary of her research](https://github.com/rust-lang/leadership-council/issues/273#issuecomment-4051188890), although we have taken the liberty of moving the Rust project's prior art to the top. We thank her for her help. ### Rust - [Moderation team's spam policy](https://github.com/rust-lang/moderation-team/blob/main/policies/spam.md/#fully-or-partially-automated-contribs) - [Compiler team's "burdensome PRs" policy](https://github.com/rust-lang/compiler-team/issues/893) ### Other organizations These are organized along a spectrum of AI friendliness, where top is least friendly, and bottom is most friendly. - full ban - [postmarketOS](https://docs.postmarketos.org/policies-and-processes/development/ai-policy.html) - also explicitly bans encouraging others to use AI for solving problems related to postmarketOS - multi point ethics based rational with citations included - [zig](https://ziglang.org/code-of-conduct/) - philosophical, cites [Profession (novella)](https://en.wikipedia.org/wiki/Profession_(novella)) - rooted in concerns around the construction and origins of original thought - [servo](https://book.servo.org/contributing/getting-started.html#ai-contributions) - more pragmatic, directly lists concerns around ai, fairly concise - [qemu](https://www.qemu.org/docs/master/devel/code-provenance.html#use-of-ai-content-generators) - pragmatic, focuses on copyright and licensing concerns - explicitly allows AI for exploring api, debugging, and other non generative assistance, other policies do not explicitly ban this or mention it in any way - allowed with supervision, human is ultimately responsible - [scipy](https://github.com/scipy/scipy/pull/24583/changes) - strict attribution policy including name of model - [llvm](https://llvm.org/docs/AIToolPolicy.html) - [blender](https://devtalk.blender.org/t/ai-contributions-policy/44202) - [linux kernel](https://kernel.org/doc/html/next/process/coding-assistants.html) - quite concise but otherwise seems the same as many in this category - [mesa](https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/docs/submittingpatches.rst) - framed as a contribution policy not an AI policy, AI is listed as a tool that can be used but emphasizes same requirements that author must understand the code they contribute, seems to leave room for partial understanding from new contributors. > Understand the code you write at least well enough to be able to explain why your changes are beneficial to the project. - [forgejo](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md) - bans AI for review, does not explicitly require contributors to understand code generated by ai. One could interpret the "accountability for contribution lies with contributor even if AI is used" line as implying this requirement, though their version seems poorly worded imo. - [firefox](https://firefox-source-docs.mozilla.org/contributing/ai-coding.html) - [ghostty](https://github.com/ghostty-org/ghostty/blob/main/AI_POLICY.md) - pro-AI but views "bad users" as the source of issues with it and the only reason for what ghostty considers a "strict AI policy" - [fedora](https://communityblog.fedoraproject.org/council-policy-proposal-policy-on-ai-assisted-contributions/) - clearly inspired and is cited by many of the above, but is definitely framed more pro-ai than the derived policies tend to be - [curl](https://curl.se/dev/contribute.html#on-ai-use-in-curl) - does not explicitly require humans understand contributions, otherwise policy is similar to above policies - [linux foundation](https://www.linuxfoundation.org/legal/generative-ai) - encourages usage, focuses on legal liability, mentions that tooling exists to help automate managing legal liability, does not mention specific tools - In progress - NixOS - https://github.com/NixOS/nixpkgs/issues/410741 ## Unresolved questions [unresolved-questions]: #unresolved-questions See the "Moderation guidelines" and "Drawbacks" section for a list of topics that are out of scope. --- src/SUMMARY.md | 1 + src/how-to-start-contributing.md | 4 +- src/policies/llm-usage.md | 107 +++++++++++++++++++++++++++++++ 3 files changed, 111 insertions(+), 1 deletion(-) create mode 100644 src/policies/llm-usage.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 245aedf2b..2f6ca8471 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -87,6 +87,7 @@ - [Project groups](./governance/project-groups.md) - [Policies](./policies/index.md) - [Crate ownership policy](./policies/crate-ownership.md) + - [LLM usage policy](./policies/llm-usage.md) - [Infrastructure](./infra/index.md) - [Other Installation Methods](./infra/other-installation-methods.md) - [Archive of Rust Stable Standalone Installers](./infra/archive-stable-version-installers.md) diff --git a/src/how-to-start-contributing.md b/src/how-to-start-contributing.md index 83a21ccb1..088e121aa 100644 --- a/src/how-to-start-contributing.md +++ b/src/how-to-start-contributing.md @@ -122,13 +122,15 @@ We know that starting contributing in a FOSS[^1] project could be confusing at t both contributors and reviewers have the best possible experience when collaborating in our project. To achieve this goal, we want to build trust and respect of each other's time and efforts. Our recommendation is to follow these simple guidelines: -- Start small. A big ball of code as first contribution does not help to build trust +- Start small. A big ball of code as first contribution does not help to build trust. - The work you submit is your own, meaning that you fully understand every part of it - You take care of checking in detail your work before submitting it - ask questions or signal us (with inline comments or `todo!()`) the parts you're unsure about - If you want to fix an issue but have doubts about the design, you're welcome to join our [Zulip][rust-zulip] server and ask for tips - Please respect the reviewers' time: allow some days between reviews, only ask for reviews when your code compiles and tests pass, or give an explanation for why you are asking for a review at that stage (you can keep them in draft state until they're ready for review) - Try to keep comments concise, don't worry about a perfect written communication. Strive for clarity and being to the point +See also our [LLM usage policy](./policies/llm-usage.md). + [^1]: Free-Open Source Project, see: https://en.wikipedia.org/wiki/Free_and_open-source_software ### Different kinds of contributions diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md new file mode 100644 index 000000000..76afc070d --- /dev/null +++ b/src/policies/llm-usage.md @@ -0,0 +1,107 @@ +## Policy + +For additional information about the policy itself, see [the appendix](#appendix). + +### Overview + +Using an LLM while working on `rust-lang/rust` is conditionally allowed. +However, we find it important to keep the following points in mind: + +- Many people find LLM-generated code and writing deeply unpleasant to read or review. +- Many people find LLMs to be a significant aid to learning and discovery. + +Therefore, the guidelines are roughly as follows: + +> It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to **create**. + +> LLMs work best when used as a tool to write *better*, not *faster*. + +#### Legend + +- ✅ Allowed +- ❌ Banned +- ⚠️ Allowed with caveats. Must disclose that an LLM was used. +- ℹ️ Adds additional detail to the policy. These bullets are normative. + +### Rules + +#### ✅ Allowed +The following are allowed. +- Asking an LLM questions about an existing codebase. +- Asking an LLM to summarize comments on an issue, PR, or RFC. + - ℹ️ This does not allow reposting the summary publicly. This only includes your own personal use. +- Asking an LLM to privately review your code or writing. + - ℹ️ This does not apply to public comments. See "review bots" under ⚠️ below. +- Writing dev-tools for your own personal use using an LLM, as long as you don't try to merge them into `rust-lang/rust`. +- Using an LLM to discover bugs, as long as you personally verify the bug, write it up yourself, and disclose that an LLM was used. + Please refer to [our guidelines for fuzzers](https://rustc-dev-guide.rust-lang.org/fuzzing.html#guidelines). + - ℹ️ This also includes reviewers who use LLMs to discover bugs in unmerged code. + +#### ❌ Banned +The following are banned. +- Comments from a personal user account that are originally authored by an LLM. + - ℹ️ This also applies to issue bodies and PR descriptions. + - ℹ️ See also "machine-translation" in ⚠️ below. +- Documentation that is originally authored by an LLM. + - ℹ️ This includes non-trivial source comments, such as paragraph+ doc-comments or multiple inline paragraphs. + - ℹ️ This includes compiler diagnostics. +- Code changes that are originally authored by an LLM. + - This does not include "trivial" changes that do not meet the [threshold of originality](https://fsfe.org/news/2025/news-20250515-01.en.html), which fall under ⚠️ below. + We understand that while asking an LLM research questions it may, unprompted, suggest small changes where there really isn't another way to write it. + However, you must still type out the changes yourself; you cannot give the LLM write access to your source code. + - We do not accept PRs made up solely of trivial changes. + See [the compiler team's typo fix policy](https://rustc-dev-guide.rust-lang.org/contributing.html#writing-documentation:~:text=Please%20notice%20that%20we%20don%E2%80%99t%20accept%20typography%2Fspellcheck%20fixes%20to%20internal%20documentation). + - See also "learning from an LLM's solution" in ⚠️ below. + +#### ⚠️ Allowed with caveats +The following are decided on a case-by-case basis. +Please avoid them where possible. +In general, existing contributors will be treated more leniently here than new contributors. +We may ask you for the original prompts or design documents that went into the LLM's output; +please have them on-hand, and be available yourself to answer questions about your process. + +- Using an LLM to generate a solution to an issue, learning from its solution, and then rewriting it from scratch in your own style. +- Using machine-translation from your native language without posting your original message. + Doing so can introduce new miscommunications that weren't there originally, and prevents someone who speaks the language from providing a better translation. + - ℹ️ Posting both your original message and the translated version is always ok, but you must still disclose that machine-translation was used. + - ℹ️ This policy also applies to non-LLM machine translations such as Google Translate. +- Using an LLM as a "review bot" for PRs. + - ℹ️ Review bots **must** have a separate GitHub account that marks them as an LLM. They **must not** post under a personal account. + - ℹ️ Review bots that post without being approved by a maintainer will be banned. + - ℹ️ If a linter already exists for the language you're writing, we strongly suggest using that linter instead of or in addition to the LLM. + - ℹ️ Please keep in mind that it's easy for LLM reviews to have false positives or focus on trivialities. We suggest configuring it to the "least chatty" setting you can. + - ℹ️ LLM comments **must not** be blocking; reviewers must indicate which comments they want addressed. It's ok to require a *response* to each comment but the response can be "the bot's wrong here". + - In other words, reviewers must explicitly endorse an LLM comment before blocking a PR. They are responsible for their own analysis of the LLM's comment and cannot treat it as a CI failure. + - ℹ️ This does not apply to private use of an LLM for reviews; see ✅ above. + +All of these **must** disclose that an LLM was used. + +## Appendix + +### No witch hunts +["The optimal amount of fraud is not zero"](https://www.bitsaboutmoney.com/archive/optimal-amount-of-fraud/). +Do not try to be the police for whether someone has used an LLM. +If it's clear they've broken the rules, point them to this policy; if it's borderline, report it to the mods and move on. + +Conversely, lying about whether you've used an LLM is an instant code of conduct violation. +If you are not sure where you fall in this policy, please talk to us. +Don't try to hide it. + +### Responsibility + +All contributions are your responsibility; you cannot place any blame on an LLM. +- ℹ️ This includes when asking people to address review comments originally authored by an LLM. See "review bots" under ⚠️ above. + +### "originally authored" + +This document uses the phrase "originally authored" to mean "text that was generated by an LLM (and then possibly edited by a human)". +No amount of editing can change authorship; authorship sets the initial style and it is very hard to change once it's set. + +For more background about analogous reasoning, see ["What Colour are your bits?"](https://ansuz.sooke.bc.ca/entry/23) + +### Non-exhaustive policy + +This policy does not aim to be exhaustive. +If you have a use of LLMs in mind that isn't on this list, judge it in the spirit of this overview: +- Usages that do not use LLMs for creation and do not show LLM output to another human are likely allowed ✅ +- Usages that use LLMs for creation or show LLM output to another human are likely banned ❌ From 815da6eaed40bb1b045cc89d37fa4287e505744f Mon Sep 17 00:00:00 2001 From: jyn Date: Fri, 17 Apr 2026 13:03:11 +0200 Subject: [PATCH 02/12] address some of jieyouxu's comments --- src/policies/llm-usage.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 76afc070d..70b6823ea 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -43,7 +43,7 @@ The following are banned. - ℹ️ This also applies to issue bodies and PR descriptions. - ℹ️ See also "machine-translation" in ⚠️ below. - Documentation that is originally authored by an LLM. - - ℹ️ This includes non-trivial source comments, such as paragraph+ doc-comments or multiple inline paragraphs. + - ℹ️ This includes non-trivial source comments, such as doc-comments or multiple paragraphs of non-doc-comments. - ℹ️ This includes compiler diagnostics. - Code changes that are originally authored by an LLM. - This does not include "trivial" changes that do not meet the [threshold of originality](https://fsfe.org/news/2025/news-20250515-01.en.html), which fall under ⚠️ below. @@ -52,6 +52,12 @@ The following are banned. - We do not accept PRs made up solely of trivial changes. See [the compiler team's typo fix policy](https://rustc-dev-guide.rust-lang.org/contributing.html#writing-documentation:~:text=Please%20notice%20that%20we%20don%E2%80%99t%20accept%20typography%2Fspellcheck%20fixes%20to%20internal%20documentation). - See also "learning from an LLM's solution" in ⚠️ below. +- Treating an LLM review as a sufficient condition to merge a change. + LLM reviews, if enabled by a team, **must** be advisory-only. + Teams can have a policy that code can be merged without review, and they can have a policy that code must be reviewed by at least one person, + but they may not have a policy that an LLM counts as a person. + - ℹ️ See "review bots" in ⚠️ below. + - ℹ️ An LLM review does not substitute for self-review. Authors are expected to review their own code before posting and after each change. #### ⚠️ Allowed with caveats The following are decided on a case-by-case basis. @@ -83,7 +89,7 @@ All of these **must** disclose that an LLM was used. Do not try to be the police for whether someone has used an LLM. If it's clear they've broken the rules, point them to this policy; if it's borderline, report it to the mods and move on. -Conversely, lying about whether you've used an LLM is an instant code of conduct violation. +Conversely, lying about whether you've used an LLM is an instant [code of conduct](https://rust-lang.org/policies/code-of-conduct/) violation. If you are not sure where you fall in this policy, please talk to us. Don't try to hide it. @@ -105,3 +111,6 @@ This policy does not aim to be exhaustive. If you have a use of LLMs in mind that isn't on this list, judge it in the spirit of this overview: - Usages that do not use LLMs for creation and do not show LLM output to another human are likely allowed ✅ - Usages that use LLMs for creation or show LLM output to another human are likely banned ❌ + +This policy is not set in stone. +We can evolve it as we gain more experience working with LLMs. From 17a35f405be7d852ba4bb97be13279a34465b5cd Mon Sep 17 00:00:00 2001 From: Jynn Nelson Date: Fri, 17 Apr 2026 17:05:57 +0200 Subject: [PATCH 03/12] revert extraneous change --- src/how-to-start-contributing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/how-to-start-contributing.md b/src/how-to-start-contributing.md index 088e121aa..4489db80d 100644 --- a/src/how-to-start-contributing.md +++ b/src/how-to-start-contributing.md @@ -122,7 +122,7 @@ We know that starting contributing in a FOSS[^1] project could be confusing at t both contributors and reviewers have the best possible experience when collaborating in our project. To achieve this goal, we want to build trust and respect of each other's time and efforts. Our recommendation is to follow these simple guidelines: -- Start small. A big ball of code as first contribution does not help to build trust. +- Start small. A big ball of code as first contribution does not help to build trust - The work you submit is your own, meaning that you fully understand every part of it - You take care of checking in detail your work before submitting it - ask questions or signal us (with inline comments or `todo!()`) the parts you're unsure about - If you want to fix an issue but have doubts about the design, you're welcome to join our [Zulip][rust-zulip] server and ask for tips From 61e5e2c8ef9ddbb54b303bee23d043c272eb9033 Mon Sep 17 00:00:00 2001 From: jyn Date: Sat, 18 Apr 2026 09:32:12 +0200 Subject: [PATCH 04/12] address some more review comments --- src/policies/llm-usage.md | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 70b6823ea..8dff7f54e 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -1,4 +1,4 @@ -## Policy +## LLM Usage Policy For additional information about the policy itself, see [the appendix](#appendix). @@ -35,7 +35,7 @@ The following are allowed. - Writing dev-tools for your own personal use using an LLM, as long as you don't try to merge them into `rust-lang/rust`. - Using an LLM to discover bugs, as long as you personally verify the bug, write it up yourself, and disclose that an LLM was used. Please refer to [our guidelines for fuzzers](https://rustc-dev-guide.rust-lang.org/fuzzing.html#guidelines). - - ℹ️ This also includes reviewers who use LLMs to discover bugs in unmerged code. + - ℹ️ This also includes reviewers who use LLMs to discover flaws in unmerged code. #### ❌ Banned The following are banned. @@ -62,20 +62,22 @@ The following are banned. #### ⚠️ Allowed with caveats The following are decided on a case-by-case basis. Please avoid them where possible. -In general, existing contributors will be treated more leniently here than new contributors. +In general, existing contributors will be treated more leniently here than new contributors, +since they've already established trust with their reviewers. We may ask you for the original prompts or design documents that went into the LLM's output; please have them on-hand, and be available yourself to answer questions about your process. - Using an LLM to generate a solution to an issue, learning from its solution, and then rewriting it from scratch in your own style. -- Using machine-translation from your native language without posting your original message. +- Using machine-translation (e.g. Google Translate) from your native language without posting your original message. Doing so can introduce new miscommunications that weren't there originally, and prevents someone who speaks the language from providing a better translation. - ℹ️ Posting both your original message and the translated version is always ok, but you must still disclose that machine-translation was used. - - ℹ️ This policy also applies to non-LLM machine translations such as Google Translate. - Using an LLM as a "review bot" for PRs. - - ℹ️ Review bots **must** have a separate GitHub account that marks them as an LLM. They **must not** post under a personal account. + - ℹ️ Review bots **must** have a separate GitHub account that marks them as an LLM. + You **must not** post (or allow a tool to post) LLM reviews verbatim on your personal account unless clearly quoted with your own personal interpretation of the bot's analysis. + - ℹ️ Review bot accounts must be blockable by individual users via the standard GitHub user-blocking mechanism. (Note that some GitHub "app" accounts post comments that look like users but cannot be blocked.) - ℹ️ Review bots that post without being approved by a maintainer will be banned. - ℹ️ If a linter already exists for the language you're writing, we strongly suggest using that linter instead of or in addition to the LLM. - - ℹ️ Please keep in mind that it's easy for LLM reviews to have false positives or focus on trivialities. We suggest configuring it to the "least chatty" setting you can. + - ℹ️ Configure LLM review tools to reduce false positives and excessive focus on trivialities, as these are common, exhausting failure modes. - ℹ️ LLM comments **must not** be blocking; reviewers must indicate which comments they want addressed. It's ok to require a *response* to each comment but the response can be "the bot's wrong here". - In other words, reviewers must explicitly endorse an LLM comment before blocking a PR. They are responsible for their own analysis of the LLM's comment and cannot treat it as a CI failure. - ℹ️ This does not apply to private use of an LLM for reviews; see ✅ above. @@ -84,21 +86,21 @@ All of these **must** disclose that an LLM was used. ## Appendix -### No witch hunts +### It's not your job to play detective ["The optimal amount of fraud is not zero"](https://www.bitsaboutmoney.com/archive/optimal-amount-of-fraud/). Do not try to be the police for whether someone has used an LLM. If it's clear they've broken the rules, point them to this policy; if it's borderline, report it to the mods and move on. Conversely, lying about whether you've used an LLM is an instant [code of conduct](https://rust-lang.org/policies/code-of-conduct/) violation. -If you are not sure where you fall in this policy, please talk to us. +If you are not sure where something you would like to do falls in this policy, please talk to us. Don't try to hide it. ### Responsibility -All contributions are your responsibility; you cannot place any blame on an LLM. +Your contributions are your responsibility; you cannot place any blame on an LLM. - ℹ️ This includes when asking people to address review comments originally authored by an LLM. See "review bots" under ⚠️ above. -### "originally authored" +### The meaning of "originally authored" This document uses the phrase "originally authored" to mean "text that was generated by an LLM (and then possibly edited by a human)". No amount of editing can change authorship; authorship sets the initial style and it is very hard to change once it's set. From 8ee5ed40b15521b02aa33f50c471b2f53bff509f Mon Sep 17 00:00:00 2001 From: jyn Date: Sat, 18 Apr 2026 09:44:17 +0200 Subject: [PATCH 05/12] more review comments --- src/policies/llm-usage.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 8dff7f54e..5fda2c4f9 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -52,7 +52,7 @@ The following are banned. - We do not accept PRs made up solely of trivial changes. See [the compiler team's typo fix policy](https://rustc-dev-guide.rust-lang.org/contributing.html#writing-documentation:~:text=Please%20notice%20that%20we%20don%E2%80%99t%20accept%20typography%2Fspellcheck%20fixes%20to%20internal%20documentation). - See also "learning from an LLM's solution" in ⚠️ below. -- Treating an LLM review as a sufficient condition to merge a change. +- Treating an LLM review as a sufficient condition to merge or reject a change. LLM reviews, if enabled by a team, **must** be advisory-only. Teams can have a policy that code can be merged without review, and they can have a policy that code must be reviewed by at least one person, but they may not have a policy that an LLM counts as a person. @@ -66,6 +66,7 @@ In general, existing contributors will be treated more leniently here than new c since they've already established trust with their reviewers. We may ask you for the original prompts or design documents that went into the LLM's output; please have them on-hand, and be available yourself to answer questions about your process. +We may also ask for the exact LLM model used to generate the output. - Using an LLM to generate a solution to an issue, learning from its solution, and then rewriting it from scratch in your own style. - Using machine-translation (e.g. Google Translate) from your native language without posting your original message. From 7cd8c17b33384f79f0d1758f0e6989b582d9c3a6 Mon Sep 17 00:00:00 2001 From: jyn Date: Sat, 18 Apr 2026 18:41:11 +0200 Subject: [PATCH 06/12] more wording --- src/policies/llm-usage.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 5fda2c4f9..6d04d5eee 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -65,7 +65,7 @@ Please avoid them where possible. In general, existing contributors will be treated more leniently here than new contributors, since they've already established trust with their reviewers. We may ask you for the original prompts or design documents that went into the LLM's output; -please have them on-hand, and be available yourself to answer questions about your process. +please have them on-hand, and be available to personally answer questions about your process. We may also ask for the exact LLM model used to generate the output. - Using an LLM to generate a solution to an issue, learning from its solution, and then rewriting it from scratch in your own style. @@ -77,7 +77,7 @@ We may also ask for the exact LLM model used to generate the output. You **must not** post (or allow a tool to post) LLM reviews verbatim on your personal account unless clearly quoted with your own personal interpretation of the bot's analysis. - ℹ️ Review bot accounts must be blockable by individual users via the standard GitHub user-blocking mechanism. (Note that some GitHub "app" accounts post comments that look like users but cannot be blocked.) - ℹ️ Review bots that post without being approved by a maintainer will be banned. - - ℹ️ If a linter already exists for the language you're writing, we strongly suggest using that linter instead of or in addition to the LLM. + - ℹ️ If a more reliable tool, such as a linter or formatter, already exists for the language you're writing, we strongly suggest using that tool instead of or in addition to the LLM. - ℹ️ Configure LLM review tools to reduce false positives and excessive focus on trivialities, as these are common, exhausting failure modes. - ℹ️ LLM comments **must not** be blocking; reviewers must indicate which comments they want addressed. It's ok to require a *response* to each comment but the response can be "the bot's wrong here". - In other words, reviewers must explicitly endorse an LLM comment before blocking a PR. They are responsible for their own analysis of the LLM's comment and cannot treat it as a CI failure. From 2db74657fe433436848b4ab53bcc03c784c94c1f Mon Sep 17 00:00:00 2001 From: Jynn Nelson Date: Tue, 21 Apr 2026 02:21:06 +0200 Subject: [PATCH 07/12] rewrite "trivial changes" section --- src/policies/llm-usage.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 6d04d5eee..c2b819623 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -46,12 +46,10 @@ The following are banned. - ℹ️ This includes non-trivial source comments, such as doc-comments or multiple paragraphs of non-doc-comments. - ℹ️ This includes compiler diagnostics. - Code changes that are originally authored by an LLM. - - This does not include "trivial" changes that do not meet the [threshold of originality](https://fsfe.org/news/2025/news-20250515-01.en.html), which fall under ⚠️ below. - We understand that while asking an LLM research questions it may, unprompted, suggest small changes where there really isn't another way to write it. - However, you must still type out the changes yourself; you cannot give the LLM write access to your source code. - - We do not accept PRs made up solely of trivial changes. - See [the compiler team's typo fix policy](https://rustc-dev-guide.rust-lang.org/contributing.html#writing-documentation:~:text=Please%20notice%20that%20we%20don%E2%80%99t%20accept%20typography%2Fspellcheck%20fixes%20to%20internal%20documentation). - - See also "learning from an LLM's solution" in ⚠️ below. + - ℹ️ This does not include "trivial" changes that do not meet the [threshold of originality](https://fsfe.org/news/2025/news-20250515-01.en.html), which fall under ⚠️ below. + - ℹ️ Be cautious about PRs that consist solely of trivial changes. + See also [the compiler team's typo fix policy](https://rustc-dev-guide.rust-lang.org/contributing.html#writing-documentation:~:text=Please%20notice%20that%20we%20don%E2%80%99t%20accept%20typography%2Fspellcheck%20fixes%20to%20internal%20documentation). + - See also "learning from an LLM's solution" in ⚠️ below. - Treating an LLM review as a sufficient condition to merge or reject a change. LLM reviews, if enabled by a team, **must** be advisory-only. Teams can have a policy that code can be merged without review, and they can have a policy that code must be reviewed by at least one person, From 9b2b3c28f49102c70fb13cd6744bb73aa069edd2 Mon Sep 17 00:00:00 2001 From: Jynn Nelson Date: Tue, 21 Apr 2026 02:21:19 +0200 Subject: [PATCH 08/12] rewrite intro to 'Allowed with caveats' --- src/policies/llm-usage.md | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index c2b819623..1ecf74a35 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -53,18 +53,14 @@ The following are banned. - Treating an LLM review as a sufficient condition to merge or reject a change. LLM reviews, if enabled by a team, **must** be advisory-only. Teams can have a policy that code can be merged without review, and they can have a policy that code must be reviewed by at least one person, - but they may not have a policy that an LLM counts as a person. + but they may not have a policy that an LLM review substitutes for a human review. - ℹ️ See "review bots" in ⚠️ below. - ℹ️ An LLM review does not substitute for self-review. Authors are expected to review their own code before posting and after each change. #### ⚠️ Allowed with caveats The following are decided on a case-by-case basis. -Please avoid them where possible. -In general, existing contributors will be treated more leniently here than new contributors, -since they've already established trust with their reviewers. -We may ask you for the original prompts or design documents that went into the LLM's output; -please have them on-hand, and be available to personally answer questions about your process. -We may also ask for the exact LLM model used to generate the output. +In general, new contributors will be scrutinized more heavily than existing contributors, +since they haven't yet established trust with their reviewers. - Using an LLM to generate a solution to an issue, learning from its solution, and then rewriting it from scratch in your own style. - Using machine-translation (e.g. Google Translate) from your native language without posting your original message. From e3b1394a0da1cefd3db5f63e087663bfaf89ea25 Mon Sep 17 00:00:00 2001 From: Jynn Nelson Date: Tue, 21 Apr 2026 02:21:39 +0200 Subject: [PATCH 09/12] Be more specific in "Moderation policy" --- src/policies/llm-usage.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 1ecf74a35..f04d01757 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -81,15 +81,21 @@ All of these **must** disclose that an LLM was used. ## Appendix -### It's not your job to play detective +### Moderation policy +#### It's not your job to play detective ["The optimal amount of fraud is not zero"](https://www.bitsaboutmoney.com/archive/optimal-amount-of-fraud/). Do not try to be the police for whether someone has used an LLM. If it's clear they've broken the rules, point them to this policy; if it's borderline, report it to the mods and move on. -Conversely, lying about whether you've used an LLM is an instant [code of conduct](https://rust-lang.org/policies/code-of-conduct/) violation. -If you are not sure where something you would like to do falls in this policy, please talk to us. +#### Be honest +Conversely, lying about whether or how you've used an LLM is considered a [code of conduct](https://rust-lang.org/policies/code-of-conduct/) violation. +If you are not sure where something you would like to do falls in this policy, please talk to the [moderation team](mailto:rust-mods@rust-lang.org). Don't try to hide it. +#### Penalties +This policy follows the same guidelines as the code of conduct: +Violations will first result in a warning, and repeated violations may result in a ban. + ### Responsibility Your contributions are your responsibility; you cannot place any blame on an LLM. From e3f2aec2958b28b906be7dc7e703dc0b61d56938 Mon Sep 17 00:00:00 2001 From: Jynn Nelson Date: Tue, 21 Apr 2026 02:22:00 +0200 Subject: [PATCH 10/12] Add explicit conditions for modification or removal --- src/policies/llm-usage.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index f04d01757..2cea47e72 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -115,5 +115,14 @@ If you have a use of LLMs in mind that isn't on this list, judge it in the spiri - Usages that do not use LLMs for creation and do not show LLM output to another human are likely allowed ✅ - Usages that use LLMs for creation or show LLM output to another human are likely banned ❌ -This policy is not set in stone. -We can evolve it as we gain more experience working with LLMs. +### Conditions for modification or dissolution +This policy is not set in stone, and we can evolve it as we gain more experience working with LLMs. + +Minor changes, such as typo fixes, only require a normal PR approval. +Major changes, such as adding a new rule or cancelling an existing rule, require +a simple majority of members of teams using rust-lang/rust (without concerns). + +This policy can be dissolved in a few ways: + +- An accepted FCP by teams using rust-lang/rust. +- An objective concern raised about active harm the policy is having on the reputation of Rust, with evidence; as decided by a leadership council FCP. From 864428fe21c44658d126e95c5bf2392db038cd93 Mon Sep 17 00:00:00 2001 From: Jynn Nelson Date: Tue, 21 Apr 2026 10:34:09 +0200 Subject: [PATCH 11/12] mention that the policy is intentionally conservative --- src/policies/llm-usage.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 2cea47e72..0be8e617b 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -9,6 +9,8 @@ However, we find it important to keep the following points in mind: - Many people find LLM-generated code and writing deeply unpleasant to read or review. - Many people find LLMs to be a significant aid to learning and discovery. +- LLMs are a new technology, and we are still learning how to use, moderate, and improve them. + Since we're still learning, we have chosen an intentionally conservative policy that lets us maintain the standard of quality that Rust is known for. Therefore, the guidelines are roughly as follows: From 593d5386c838d682a94fd8e55a72693fce9c546f Mon Sep 17 00:00:00 2001 From: Jynn Nelson Date: Tue, 21 Apr 2026 10:34:26 +0200 Subject: [PATCH 12/12] extend "Penalties" section with sentencing guidelines --- src/policies/llm-usage.md | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 0be8e617b..be2477451 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -95,8 +95,17 @@ If you are not sure where something you would like to do falls in this policy, p Don't try to hide it. #### Penalties -This policy follows the same guidelines as the code of conduct: +The policies below follow the same guidelines as the code of conduct: Violations will first result in a warning, and repeated violations may result in a ban. +- 🔨 Comments from a personal account originally authored by an LLM +- 🔨 Violations of the "Be honest" section + +Other violations are left up to the discretion of reviewers and moderators. +For most cases we recommend closing and locking the PR or issue, but not escalating further. + +Using an LLM does **not** mean it's ok to harrass a contributor. +All contributors must be treated with respect. +The code-of-conduct applies to *all* conversations in the Rust project. ### Responsibility