[llvm] [docs] Strengthen our quality standards and connect AI contribution policy to it (PR #154441)
Reid Kleckner via llvm-commits
llvm-commits at lists.llvm.org
Wed Oct 1 15:22:41 PDT 2025
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/154441
>From b9aaea935a807f57d6041166357bc2df69257dec Mon Sep 17 00:00:00 2001
From: Reid Kleckner <rnk at google.com>
Date: Fri, 18 Jul 2025 16:28:44 -0700
Subject: [PATCH 1/6] [docs] Strengthen our quality standards and connect AI
contribution policy to it
Open source projects are often the target of nuisance contributions
(think typo corrections), but prior to the advent of AI tools, we hadn't
had to take a strong policy stance discouraging these contributions.
However, as the tools have improved, the skill required to make
plausible contributions has decreased, and burdensome nuisance
contributions have become a problem for our project, so I think we
should adopt a stronger quality bar policy.
I've updated our existing Quality section to frame everything in terms
of a golden rule that contributions should pass subjective maintainer
quality standards, held in balance against our desire to welcome new
contributors.
I then connected the AI policy section to our core quality policy, to
try to make the AI policy section tool-neutral. My goal is to minimize
the distinction between traditional mass-refactoring tools, and the
costs of those migrations, and AI-assisted contributions.
This is following up on a discussion in the July 17 LLVM project council
meeting.
---
llvm/docs/DeveloperPolicy.rst | 182 ++++++++++++++++++++++++----------
1 file changed, 132 insertions(+), 50 deletions(-)
diff --git a/llvm/docs/DeveloperPolicy.rst b/llvm/docs/DeveloperPolicy.rst
index eb59c4953dc2d..a8be0ed1ba782 100644
--- a/llvm/docs/DeveloperPolicy.rst
+++ b/llvm/docs/DeveloperPolicy.rst
@@ -293,57 +293,63 @@ warranted when performing a code review.
Quality
-------
-The minimum quality standards that any change must satisfy before being
-committed to the main development branch are:
-
-#. Code must adhere to the `LLVM Coding Standards <CodingStandards.html>`_.
-
-#. Code must compile cleanly (no errors, no warnings) on at least one platform.
+Sending patches, PRs, RFCs, comments, etc to LLVM, is not free -- it takes a lot
+of maintainer time and energy to review those contributions. Our quality bar can
+be summarized with the **golden rule** that a contribution should be worth more
+to the project than the time it takes to review it.
+
+However, this rule is held in balance with our goal to make the LLVM project
+welcoming and open to aspiring compiler engineers who are willing to invest time
+and effort to learn and grow, because growing our contributor base and
+potentially recruiting new maintainers helps sustain the project over the long
+term.
+
+Contributors who repeatedly make low-value contributions according to the
+standards of our maintainers will be asked to increase the quality of their
+contributions or cease contributing. As a community, we encourage maintainers to
+invest effort in reviewing work from new contributors. We label PRs from
+first-time contributors to set maintainer expectations on quality. However, we
+expect to see a growth pattern in the quality of a contributor's work over time.
+Maintainers can use their discretion and push back against burdensome
+contributions and ask contributors to meet their quality bar. In addition to the
+minimum guidelines outlined in thie section, maintainers can set their own
+quality standards using their considerable domain expertise.
+
+The following is a checklist of some of the minimum quality standards that any
+change must satisfy before being reviewed in detail or committed to the main
+development branch:
#. Bug fixes and new features should `include a testcase`_ so we know if the
fix/feature ever regresses in the future.
-#. Code must pass the ``llvm/test`` test suite.
+#. The code should compile cleanly on all supported platforms.
-#. The code must not cause regressions on a reasonable subset of llvm-test,
- where "reasonable" depends on the contributor's judgement and the scope of
- the change (more invasive changes require more testing). A reasonable subset
- might be something like "``llvm-test/MultiSource/Benchmarks``".
+#. Code must pass the relevant regression test suites on all supported
+ plaftorms.
+
+#. Code must adhere to the `LLVM Coding Standards <CodingStandards.html>`_.
#. Ensure that links in source code and test files point to publicly available
resources and are used primarily to add additional information rather than
to supply critical context. The surrounding comments should be sufficient
to provide the context behind such links.
-Additionally, the committer is responsible for addressing any problems found in
-the future that the change is responsible for. For example:
-
-* The code should compile cleanly on all supported platforms.
-
-* The changes should not cause any correctness regressions in the ``llvm-test``
- suite and must not cause any major performance regressions.
-
-* The change set should not cause performance or correctness regressions for the
- LLVM tools.
+Our quality policy goals are captured by this quote from `Working in Public: The
+Making and Maintenance of Open Source Software
+<https://press.stripe.com/working-in-public>`_ by Nadia Eghbal:
-* The changes should not cause performance or correctness regressions in code
- compiled by LLVM on all applicable targets.
-
-* You are expected to address any `GitHub Issues <https://github.com/llvm/llvm-project/issues>`_ that
- result from your change.
+ .. pull-quote::
-We prefer for this to be handled before submission but understand that it isn't
-possible to test all of this for every submission. Our build bots and nightly
-testing infrastructure normally finds these problems. A good rule of thumb is
-to check the nightly testers for regressions the day after your change. Build
-bots will directly email you if a group of commits that included yours caused a
-failure. You are expected to check the build bot messages to see if they are
-your fault and, if so, fix the breakage.
+ "When attention is being appropriated, producers need to weigh the costs and
+ benefits of the transaction. To assess whether the appropriation of attention
+ is net-positive, it’s useful to distinguish between *extractive* and
+ *non-extractive* contributions. Extractive contributions are those where the
+ marginal cost of reviewing and merging that contribution is greater than the
+ marginal benefit to the project’s producers. In the case of a code
+ contribution, it might be a pull request that’s too complex or unwieldy to
+ review, given the potential upside."
+ -- Nadia Eghbal
-Commits that violate these quality standards (e.g. are very broken) may be
-reverted. This is necessary when the change blocks other developers from making
-progress. The developer is welcome to re-commit the change after the problem has
-been fixed.
.. _commit messages:
@@ -424,6 +430,39 @@ squashing and merging PRs.
For minor violations of these recommendations, the community normally favors
reminding the contributor of this policy over reverting.
+Post-commit responsibilities
+----------------------------
+
+After landing a change, the committer is responsible for addressing any problems
+found in the future that the change is responsible for. For example:
+
+* The code should compile cleanly on all supported platforms.
+
+* The changes should not cause any correctness regressions in the ``llvm-test``
+ suite and must not cause any major performance regressions.
+
+* The change set should not cause performance or correctness regressions for the
+ LLVM tools.
+
+* The changes should not cause performance or correctness regressions in code
+ compiled by LLVM on all applicable targets.
+
+* You are expected to address any `GitHub Issues <https://github.com/llvm/llvm-project/issues>`_ that
+ result from your change.
+
+We prefer for this to be handled before submission but understand that it isn't
+possible to test all of this for every submission. Our build bots and nightly
+testing infrastructure normally finds these problems. A good rule of thumb is
+to check the nightly testers for regressions the day after your change. Build
+bots will directly email you if a group of commits that included yours caused a
+failure. You are expected to check the build bot messages to see if they are
+your fault and, if so, fix the breakage.
+
+Commits that violate these quality standards (e.g. are very broken) may be
+reverted. This is necessary when the change blocks other developers from making
+progress. The developer is welcome to re-commit the change after the problem has
+been fixed.
+
.. _revert_policy:
Patch reversion policy
@@ -1458,6 +1497,13 @@ permission.
AI generated contributions
--------------------------
+LLVM's policy on AI-assisted tooling is fundamentally liberal -- We want to
+enable contributors to use the latest and greatest tools available. Our policy
+guided by two major concerns:
+
+1. Ensuring that contributions do not contain copyrighted content.
+2. Ensuring that contributions are not burdensome and exceed our `quality`_ bar.
+
Artificial intelligence systems raise many questions around copyright that have
yet to be answered. Our policy on AI tools is guided by our copyright policy:
Contributors are responsible for ensuring that they have the right to contribute
@@ -1465,16 +1511,52 @@ code under the terms of our license, typically meaning that either they, their
employer, or their collaborators hold the copyright. Using AI tools to
regenerate copyrighted material does not remove the copyright, and contributors
are responsible for ensuring that such material does not appear in their
-contributions.
-
-As such, the LLVM policy is that contributors are permitted to use artificial
-intelligence tools to produce contributions, provided that they have the right
-to license that code under the project license. Contributions found to violate
-this policy will be removed just like any other offending contribution.
-
-While the LLVM project has a liberal policy on AI tool use, contributors are
-considered responsible for their contributions. We encourage contributors to
-review all generated code before sending it for review to verify its
-correctness and to understand it so that they can answer questions during code
-review. Reviewing and maintaining generated code that the original contributor
-does not understand is not a good use of limited project resources.
+contributions. Contributions found to violate this policy will be removed just
+like any other offending contribution.
+
+Recent improvements in AI-assisted tooling have made it easy to generate large
+volumes of code and text with little effort on the part of the contributor. This
+has increased the asymmetry between the work of producing a contribution, and
+the work of reviewing the contribution. In order to protect the time and
+attentional resources of LLVM project maintainers, the onus is on contributors
+to justify why their contributions are not burdensome and exceed our `quality`_
+bar. Contributors who repeatedly send low-quality contributions to our project
+will be subject to escalating moderation actions and eventually a project ban.
+
+This policy covers, but is not limited to, the following kinds of contributions:
+
+* Code, usually in the form of a pull request
+* RFCs or design proposals
+* Issues or security vulnerabilities
+* Comments and feedback on pull requests
+
+We encourage, but do not require, contributors making large changes to document
+the tools that they used as part of the rationale for why they believe their
+contribution has merit. This is similar in spirit to including a sed or Python
+script in the commit message when making large-scale changes to the project,
+such as updating the LLVM IR textual syntax.
+
+Here are some examples of contributions that demonstrate how to apply the
+principles of this policy:
+
+* `This PR <https://github.com/llvm/llvm-project/pull/142869>`_ contains a
+ proof from Alive2, which is a strong signal of value and correctness.
+
+* This `generated documentation
+ <https://discourse.llvm.org/t/searching-for-gsym-documentation/85185/2>`_ was
+ reviewed for correctness by a human before being posted.
+
+**References:** Our policy was informed by experiences in other communities:
+
+* `Rust policy on burdensome PRs
+ <https://github.com/rust-lang/compiler-team/issues/893>`_
+
+* `Seth Larson's post <https://sethmlarson.dev/slop-security-reports>`_ on slop
+ security reports in the Python ecosystem
+
+* The METR paper `Measuring the Impact of Early-2025 AI on Experienced
+ Open-Source Developer Productivity
+ <https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/>`_.
+
+* `QEMU bans use of AI content generators
+ <https://www.qemu.org/docs/master/devel/code-provenance.html#use-of-ai-content-generators>`_
>From 8f861a0f42695ace9c78e322d48537f861615381 Mon Sep 17 00:00:00 2001
From: Reid Kleckner <rnk at google.com>
Date: Wed, 20 Aug 2025 10:52:12 -0700
Subject: [PATCH 2/6] Updating text to center it around
extractive/non-extractive contributions
---
llvm/docs/DeveloperPolicy.rst | 107 ++++++++++++++++++----------------
1 file changed, 58 insertions(+), 49 deletions(-)
diff --git a/llvm/docs/DeveloperPolicy.rst b/llvm/docs/DeveloperPolicy.rst
index a8be0ed1ba782..cfb35591afe5c 100644
--- a/llvm/docs/DeveloperPolicy.rst
+++ b/llvm/docs/DeveloperPolicy.rst
@@ -294,49 +294,11 @@ Quality
-------
Sending patches, PRs, RFCs, comments, etc to LLVM, is not free -- it takes a lot
-of maintainer time and energy to review those contributions. Our quality bar can
-be summarized with the **golden rule** that a contribution should be worth more
-to the project than the time it takes to review it.
-
-However, this rule is held in balance with our goal to make the LLVM project
-welcoming and open to aspiring compiler engineers who are willing to invest time
-and effort to learn and grow, because growing our contributor base and
-potentially recruiting new maintainers helps sustain the project over the long
-term.
-
-Contributors who repeatedly make low-value contributions according to the
-standards of our maintainers will be asked to increase the quality of their
-contributions or cease contributing. As a community, we encourage maintainers to
-invest effort in reviewing work from new contributors. We label PRs from
-first-time contributors to set maintainer expectations on quality. However, we
-expect to see a growth pattern in the quality of a contributor's work over time.
-Maintainers can use their discretion and push back against burdensome
-contributions and ask contributors to meet their quality bar. In addition to the
-minimum guidelines outlined in thie section, maintainers can set their own
-quality standards using their considerable domain expertise.
-
-The following is a checklist of some of the minimum quality standards that any
-change must satisfy before being reviewed in detail or committed to the main
-development branch:
-
-#. Bug fixes and new features should `include a testcase`_ so we know if the
- fix/feature ever regresses in the future.
-
-#. The code should compile cleanly on all supported platforms.
-
-#. Code must pass the relevant regression test suites on all supported
- plaftorms.
-
-#. Code must adhere to the `LLVM Coding Standards <CodingStandards.html>`_.
-
-#. Ensure that links in source code and test files point to publicly available
- resources and are used primarily to add additional information rather than
- to supply critical context. The surrounding comments should be sufficient
- to provide the context behind such links.
-
-Our quality policy goals are captured by this quote from `Working in Public: The
-Making and Maintenance of Open Source Software
-<https://press.stripe.com/working-in-public>`_ by Nadia Eghbal:
+of maintainer time and energy to review those contributions! Our **golden rule**
+is that a contribution should be worth more to the project than the time it
+takes to review it. These ideas are captured by this quote from the book
+`Working in Public <https://press.stripe.com/working-in-public>`_ by Nadia
+Eghbal:
.. pull-quote::
@@ -350,6 +312,52 @@ Making and Maintenance of Open Source Software
review, given the potential upside."
-- Nadia Eghbal
+We encourage non-extractive contributions that help sustain the project. We want
+the LLVM project to be welcoming and open to aspiring compiler engineers who are
+willing to invest time and effort to learn and grow, because growing our
+contributor base and recruiting new maintainers helps sustain the project over
+the long term. We therefore label pull requests from new contributors and
+encourage maintainers to spend their time to help new contributors learn.
+
+However, we expect to see a growth pattern in the quality of a contributor's
+work over time. Maintainers are empowered to push back against *extractive*
+contributions and explain why they believe a contribution is overly burdensome
+or not aligned with the project goals.
+
+Contribution size is an imperfect proxy of the burden of review, and the
+potential user base of the feature is another possible proxy for the value of
+the contribution. The best ways to make a change less extractive and more
+valuable are to reduce its size or complexity or to increase its usefulness to
+the community. These factors are impossible to weigh objectively, and our
+project policy leaves this determination up to the maintainers of the project,
+i.e. those who are doing the work of sustaining the project.
+
+While our quality policy is subjective at its core, here are some guidelines
+that can be used to assess the quality of a contribution:
+
+* Bug fixes and new features should `include a testcase`_ so we know if the
+ fix/feature ever regresses in the future.
+
+* Pull requests should build and pass premerge checks. For first-time
+ contributors, this will require an initial cursory review to run the checks.
+
+* Code must adhere to the `LLVM Coding Standards <CodingStandards.html>`_.
+
+* Ensure that links in source code and test files point to publicly available
+ resources and are used primarily to add additional information rather than to
+ supply critical context. The surrounding comments should be sufficient to
+ provide the context behind such links.
+
+* Use relevant test suites and verification tools (e.g. `Alive2
+ <https://github.com/AliveToolkit/alive2>`_) and provide evidence that they
+ pass.
+
+* RFCs and issues should be clear and concise.
+
+* Issues with compact reproducers, especially those which can be replicated on
+ `the godbolt compiler explorer <https://godbolt.org>`_, are considered high
+ quality.
+
.. _commit messages:
@@ -438,8 +446,9 @@ found in the future that the change is responsible for. For example:
* The code should compile cleanly on all supported platforms.
-* The changes should not cause any correctness regressions in the ``llvm-test``
- suite and must not cause any major performance regressions.
+* The changes should not cause any correctness regressions in the
+ `llvm-test-suite <https://github.com/llvm/llvm-test-suite>`_
+ and must not cause any major performance regressions.
* The change set should not cause performance or correctness regressions for the
LLVM tools.
@@ -447,8 +456,8 @@ found in the future that the change is responsible for. For example:
* The changes should not cause performance or correctness regressions in code
compiled by LLVM on all applicable targets.
-* You are expected to address any `GitHub Issues <https://github.com/llvm/llvm-project/issues>`_ that
- result from your change.
+* You are expected to address any `GitHub Issues
+ <https://github.com/llvm/llvm-project/issues>`_ that result from your change.
We prefer for this to be handled before submission but understand that it isn't
possible to test all of this for every submission. Our build bots and nightly
@@ -1502,7 +1511,7 @@ enable contributors to use the latest and greatest tools available. Our policy
guided by two major concerns:
1. Ensuring that contributions do not contain copyrighted content.
-2. Ensuring that contributions are not burdensome and exceed our `quality`_ bar.
+2. Ensuring that contributions are not extractive and meet our `quality`_ bar.
Artificial intelligence systems raise many questions around copyright that have
yet to be answered. Our policy on AI tools is guided by our copyright policy:
@@ -1519,7 +1528,7 @@ volumes of code and text with little effort on the part of the contributor. This
has increased the asymmetry between the work of producing a contribution, and
the work of reviewing the contribution. In order to protect the time and
attentional resources of LLVM project maintainers, the onus is on contributors
-to justify why their contributions are not burdensome and exceed our `quality`_
+to justify why their contributions are not extractive and meet our `quality`_
bar. Contributors who repeatedly send low-quality contributions to our project
will be subject to escalating moderation actions and eventually a project ban.
>From c52546af20cb10a11800c6a6c0006c39fd218595 Mon Sep 17 00:00:00 2001
From: Reid Kleckner <rnk at google.com>
Date: Mon, 25 Aug 2025 14:48:38 -0700
Subject: [PATCH 3/6] Address feedback on nightly testing and add copy-pasted
message
---
llvm/docs/DeveloperPolicy.rst | 44 +++++++++++++++++++++++------------
1 file changed, 29 insertions(+), 15 deletions(-)
diff --git a/llvm/docs/DeveloperPolicy.rst b/llvm/docs/DeveloperPolicy.rst
index cfb35591afe5c..48bc51f66cbae 100644
--- a/llvm/docs/DeveloperPolicy.rst
+++ b/llvm/docs/DeveloperPolicy.rst
@@ -324,6 +324,16 @@ work over time. Maintainers are empowered to push back against *extractive*
contributions and explain why they believe a contribution is overly burdensome
or not aligned with the project goals.
+If a maintainer judges that a contribution is extractive (i.e. it is generated
+with tool-assistance and is not valuable), they should copy-paste the following
+response, add the ``extractive`` label if applicable, and refrain from further
+engagement::
+
+ This PR appears to be extractive, and requires additional justification for
+ why it is valuable enough to the project for us to review it. Please see
+ our developer policy on quality and AI contributions:
+ http://llvm.org/docs/DeveloperPolicy.html#quality
+
Contribution size is an imperfect proxy of the burden of review, and the
potential user base of the feature is another possible proxy for the value of
the contribution. The best ways to make a change less extractive and more
@@ -441,17 +451,21 @@ reminding the contributor of this policy over reverting.
Post-commit responsibilities
----------------------------
-After landing a change, the committer is responsible for addressing any problems
-found in the future that the change is responsible for. For example:
+There are many important qualities that LLVM aims for, but which we cannot
+afford to test for as part of our premerge pipeline. After landing a change,
+the committer is responsible for addressing any problems found in the future
+that the change is responsible for. Here are some of the issues that arise
+post-commit:
-* The code should compile cleanly on all supported platforms.
+* The code needs to compile cleanly and pass tests on all stable `LLVM
+ buildbots <https://lab.llvm.org/buildbot/>`_.
* The changes should not cause any correctness regressions in the
`llvm-test-suite <https://github.com/llvm/llvm-test-suite>`_
and must not cause any major performance regressions.
* The change set should not cause performance or correctness regressions for the
- LLVM tools.
+ LLVM tools. See `llvm-compile-time-tracker.com <https://llvm-compile-time-tracker.com>`_
* The changes should not cause performance or correctness regressions in code
compiled by LLVM on all applicable targets.
@@ -459,18 +473,18 @@ found in the future that the change is responsible for. For example:
* You are expected to address any `GitHub Issues
<https://github.com/llvm/llvm-project/issues>`_ that result from your change.
-We prefer for this to be handled before submission but understand that it isn't
-possible to test all of this for every submission. Our build bots and nightly
-testing infrastructure normally finds these problems. A good rule of thumb is
-to check the nightly testers for regressions the day after your change. Build
-bots will directly email you if a group of commits that included yours caused a
+Our build bots and `nightly testing infrastructure
+<https://llvm.org/docs/lnt/intro.html>`_ find many of these issues. Build bots
+will directly email you if a group of commits that included yours caused a
failure. You are expected to check the build bot messages to see if they are
-your fault and, if so, fix the breakage.
-
-Commits that violate these quality standards (e.g. are very broken) may be
-reverted. This is necessary when the change blocks other developers from making
-progress. The developer is welcome to re-commit the change after the problem has
-been fixed.
+your fault and, if so, fix the breakage. However, keep in mind that if you
+receive such an email, it is highly likely that your change is not at fault.
+Changes are batched together precisely because these tests are generally too
+expensive to run continuously for every change.
+
+Commits that violate these quality standards may be reverted (see below). This
+is necessary when the change blocks other developers from making progress. The
+developer is welcome to re-commit the change after the problem has been fixed.
.. _revert_policy:
>From dd6e7293bb18c4666c7d18265eccb31adcc4ebf8 Mon Sep 17 00:00:00 2001
From: Reid Kleckner <rnk at google.com>
Date: Mon, 25 Aug 2025 16:22:23 -0700
Subject: [PATCH 4/6] Update wording: We comment on first-time PRs, we do not
label them (yet)
---
llvm/docs/DeveloperPolicy.rst | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/llvm/docs/DeveloperPolicy.rst b/llvm/docs/DeveloperPolicy.rst
index 48bc51f66cbae..9166fd07fd157 100644
--- a/llvm/docs/DeveloperPolicy.rst
+++ b/llvm/docs/DeveloperPolicy.rst
@@ -316,8 +316,9 @@ We encourage non-extractive contributions that help sustain the project. We want
the LLVM project to be welcoming and open to aspiring compiler engineers who are
willing to invest time and effort to learn and grow, because growing our
contributor base and recruiting new maintainers helps sustain the project over
-the long term. We therefore label pull requests from new contributors and
-encourage maintainers to spend their time to help new contributors learn.
+the long term. We therefore automatically post a greeting comment to pull
+requests from new contributors and encourage maintainers to spend their time to
+help new contributors learn.
However, we expect to see a growth pattern in the quality of a contributor's
work over time. Maintainers are empowered to push back against *extractive*
>From 89a6d2fe12e011fde11cb021898bc4416ff2aac1 Mon Sep 17 00:00:00 2001
From: Reid Kleckner <rnk at google.com>
Date: Tue, 2 Sep 2025 14:26:54 -0700
Subject: [PATCH 5/6] Move all the text into a new policy doc
---
llvm/docs/AIToolPolicy.md | 130 ++++++++++++++++++++++++++++++++++++++
llvm/docs/Reference.rst | 1 +
2 files changed, 131 insertions(+)
create mode 100644 llvm/docs/AIToolPolicy.md
diff --git a/llvm/docs/AIToolPolicy.md b/llvm/docs/AIToolPolicy.md
new file mode 100644
index 0000000000000..81effb6a11dca
--- /dev/null
+++ b/llvm/docs/AIToolPolicy.md
@@ -0,0 +1,130 @@
+# Extractive Contribution Policy
+
+LLVM's policy on AI-assisted tooling is fundamentally liberal -- We want to
+enable contributors to use the latest and greatest tools available. Our policy
+guided by two major concerns, the latter of which is the most important:
+
+1. Ensuring that contributions do not contain copyrighted content.
+2. Ensuring that contributions are not extractive and meet our
+ [quality](#quality) bar.
+
+This policy covers, but is not limited to, the following kinds of
+contributions:
+
+- Code, usually in the form of a pull request
+- RFCs or design proposals
+- Issues or security vulnerabilities
+- Comments and feedback on pull requests
+
+## Copyright
+
+Artificial intelligence systems raise many questions around copyright that have
+yet to be answered. Our policy on AI tools is similar to our copyright policy:
+Contributors are responsible for ensuring that they have the right to
+contribute code under the terms of our license, typically meaning that either
+they, their employer, or their collaborators hold the copyright. Using AI tools
+to regenerate copyrighted material does not remove the copyright, and
+contributors are responsible for ensuring that such material does not appear in
+their contributions. Contributions found to violate this policy will be removed
+just like any other offending contribution.
+
+## Quality
+
+Sending patches, PRs, RFCs, comments, etc to LLVM, is not free -- it takes a
+lot of maintainer time and energy to review those contributions! Recent
+improvements in AI-assisted tooling have made it easy to generate large volumes
+of code and text with little effort on the part of the contributor. This has
+increased the asymmetry between the work of producing a contribution, and the
+work of reviewing the contribution. Our **golden rule** is that a contribution
+should be worth more to the project than the time it takes to review it. These
+ideas are captured by this quote from the book [Working in Public][1] by
+Nadia Eghbal:
+
+[1]: https://press.stripe.com/working-in-public
+
+> \"When attention is being appropriated, producers need to weigh the costs and
+> benefits of the transaction. To assess whether the appropriation of attention
+> is net-positive, it's useful to distinguish between *extractive* and
+> *non-extractive* contributions. Extractive contributions are those where the
+> marginal cost of reviewing and merging that contribution is greater than the
+> marginal benefit to the project's producers. In the case of a code
+> contribution, it might be a pull request that's too complex or unwieldy to
+> review, given the potential upside.\" \-- Nadia Eghbal
+
+We encourage contributions that help sustain the project. We want the LLVM
+project to be welcoming and open to aspiring compiler engineers who are willing
+to invest time and effort to learn and grow, because growing our contributor
+base and recruiting new maintainers helps sustain the project over the long
+term. We therefore automatically post a greeting comment to pull requests from
+new contributors and encourage maintainers to spend their time to help new
+contributors learn.
+
+However, we expect to see a growth pattern in the quality of a contributor's
+work over time. Maintainers are empowered to push back against *extractive*
+contributions and explain why they believe a contribution is overly burdensome
+or not aligned with the project goals.
+
+If a maintainer judges that a contribution is extractive (i.e. it is generated
+with tool-assistance and is not valuable), they should copy-paste the following
+response, add the `extractive` label if applicable, and refrain from further
+engagement:
+
+ This PR appears to be extractive, and requires additional justification for
+ why it is valuable enough to the project for us to review it. Please see
+ our developer policy on extractive contributions:
+ http://llvm.org/docs/ExtractiveContributions.html
+
+Other reviewers should use the label prioritize their review time.
+
+Contributors are welcome to improve their work or make the case for why it has
+value for the community, but they should keep in mind that they may be
+moderated for excessive extractive communications.
+
+While our quality policy is subjective at its core, here are some guidelines
+that can be used to assess the quality of a contribution:
+
+- Contribution size: Larger contributions require more time to read and review.
+ RFCs and issues should be clear and concise, and pull requests should not
+ change unrelated code.
+- Potential user base: Contributions with more users are inherently more valuable.
+- Code must adhere to the [LLVM Coding Standards](CodingStandards.html).
+- Pull requests should build and pass premerge checks. For first-time
+ contributors, this will require an initial cursory review to run the
+ checks.
+
+The best ways to make a change less extractive and more valuable are to reduce
+its size or complexity or to increase its usefulness to the community. These
+factors are impossible to weigh objectively, and our project policy leaves this
+determination up to the maintainers of the project, i.e. those who are doing
+the work of sustaining the project.
+
+We encourage, but do not require, contributors making large changes to document
+the tools that they used as part of the rationale for why they believe their
+contribution has merit. This is similar in spirit to including a sed or Python
+script in the commit message when making large-scale changes to the project,
+such as updating the LLVM IR textual syntax.
+
+## Examples
+
+Here are some examples of contributions that demonstrate how to apply
+the principles of this policy:
+
+- [This PR](https://github.com/llvm/llvm-project/pull/142869) contains a
+ proof from Alive2, which is a strong signal of value and correctness.
+- This [generated
+ documentation](https://discourse.llvm.org/t/searching-for-gsym-documentation/85185/2)
+ was reviewed for correctness by a human before being posted.
+
+## References
+
+Our policy was informed by experiences in other communities:
+
+- [Rust policy on burdensome
+ PRs](https://github.com/rust-lang/compiler-team/issues/893)
+- [Seth Larson's post](https://sethmlarson.dev/slop-security-reports)
+ on slop security reports in the Python ecosystem
+- The METR paper [Measuring the Impact of Early-2025 AI on Experienced
+ Open-Source Developer
+ Productivity](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/).
+- [QEMU bans use of AI content
+ generators](https://www.qemu.org/docs/master/devel/code-provenance.html#use-of-ai-content-generators)
diff --git a/llvm/docs/Reference.rst b/llvm/docs/Reference.rst
index 7d0fdd78dc96d..dcdba0f6fe75d 100644
--- a/llvm/docs/Reference.rst
+++ b/llvm/docs/Reference.rst
@@ -9,6 +9,7 @@ LLVM and API reference documentation.
.. toctree::
:hidden:
+ AIToolPolicy
Atomics
BitCodeFormat
BlockFrequencyTerminology
>From fed0096751d90de32a1d2b10cc15883aa34f3633 Mon Sep 17 00:00:00 2001
From: Reid Kleckner <rnk at google.com>
Date: Tue, 2 Sep 2025 15:51:26 -0700
Subject: [PATCH 6/6] Restore original Developer Policy text with minimal edits
---
llvm/docs/AIToolPolicy.md | 12 +-
llvm/docs/DeveloperPolicy.rst | 226 ++++++++--------------------------
2 files changed, 56 insertions(+), 182 deletions(-)
diff --git a/llvm/docs/AIToolPolicy.md b/llvm/docs/AIToolPolicy.md
index 81effb6a11dca..c522fdcaec4c1 100644
--- a/llvm/docs/AIToolPolicy.md
+++ b/llvm/docs/AIToolPolicy.md
@@ -1,4 +1,4 @@
-# Extractive Contribution Policy
+# LLVM AI Tool Use Policy
LLVM's policy on AI-assisted tooling is fundamentally liberal -- We want to
enable contributors to use the latest and greatest tools available. Our policy
@@ -65,14 +65,14 @@ contributions and explain why they believe a contribution is overly burdensome
or not aligned with the project goals.
If a maintainer judges that a contribution is extractive (i.e. it is generated
-with tool-assistance and is not valuable), they should copy-paste the following
-response, add the `extractive` label if applicable, and refrain from further
-engagement:
+with tool-assistance or isn't valuable for other reasons), they should
+copy-paste the following response, add the `extractive` label if applicable,
+and refrain from further engagement:
This PR appears to be extractive, and requires additional justification for
why it is valuable enough to the project for us to review it. Please see
- our developer policy on extractive contributions:
- http://llvm.org/docs/ExtractiveContributions.html
+ our developer policy on AI-generated contributions:
+ http://llvm.org/docs/AIToolPolicy.html
Other reviewers should use the label prioritize their review time.
diff --git a/llvm/docs/DeveloperPolicy.rst b/llvm/docs/DeveloperPolicy.rst
index 9166fd07fd157..45b09d39709dc 100644
--- a/llvm/docs/DeveloperPolicy.rst
+++ b/llvm/docs/DeveloperPolicy.rst
@@ -293,81 +293,55 @@ warranted when performing a code review.
Quality
-------
-Sending patches, PRs, RFCs, comments, etc to LLVM, is not free -- it takes a lot
-of maintainer time and energy to review those contributions! Our **golden rule**
-is that a contribution should be worth more to the project than the time it
-takes to review it. These ideas are captured by this quote from the book
-`Working in Public <https://press.stripe.com/working-in-public>`_ by Nadia
-Eghbal:
-
- .. pull-quote::
-
- "When attention is being appropriated, producers need to weigh the costs and
- benefits of the transaction. To assess whether the appropriation of attention
- is net-positive, it’s useful to distinguish between *extractive* and
- *non-extractive* contributions. Extractive contributions are those where the
- marginal cost of reviewing and merging that contribution is greater than the
- marginal benefit to the project’s producers. In the case of a code
- contribution, it might be a pull request that’s too complex or unwieldy to
- review, given the potential upside."
- -- Nadia Eghbal
-
-We encourage non-extractive contributions that help sustain the project. We want
-the LLVM project to be welcoming and open to aspiring compiler engineers who are
-willing to invest time and effort to learn and grow, because growing our
-contributor base and recruiting new maintainers helps sustain the project over
-the long term. We therefore automatically post a greeting comment to pull
-requests from new contributors and encourage maintainers to spend their time to
-help new contributors learn.
-
-However, we expect to see a growth pattern in the quality of a contributor's
-work over time. Maintainers are empowered to push back against *extractive*
-contributions and explain why they believe a contribution is overly burdensome
-or not aligned with the project goals.
-
-If a maintainer judges that a contribution is extractive (i.e. it is generated
-with tool-assistance and is not valuable), they should copy-paste the following
-response, add the ``extractive`` label if applicable, and refrain from further
-engagement::
-
- This PR appears to be extractive, and requires additional justification for
- why it is valuable enough to the project for us to review it. Please see
- our developer policy on quality and AI contributions:
- http://llvm.org/docs/DeveloperPolicy.html#quality
-
-Contribution size is an imperfect proxy of the burden of review, and the
-potential user base of the feature is another possible proxy for the value of
-the contribution. The best ways to make a change less extractive and more
-valuable are to reduce its size or complexity or to increase its usefulness to
-the community. These factors are impossible to weigh objectively, and our
-project policy leaves this determination up to the maintainers of the project,
-i.e. those who are doing the work of sustaining the project.
-
-While our quality policy is subjective at its core, here are some guidelines
-that can be used to assess the quality of a contribution:
-
-* Bug fixes and new features should `include a testcase`_ so we know if the
- fix/feature ever regresses in the future.
-
-* Pull requests should build and pass premerge checks. For first-time
- contributors, this will require an initial cursory review to run the checks.
-
-* Code must adhere to the `LLVM Coding Standards <CodingStandards.html>`_.
-
-* Ensure that links in source code and test files point to publicly available
- resources and are used primarily to add additional information rather than to
- supply critical context. The surrounding comments should be sufficient to
- provide the context behind such links.
-
-* Use relevant test suites and verification tools (e.g. `Alive2
- <https://github.com/AliveToolkit/alive2>`_) and provide evidence that they
- pass.
-
-* RFCs and issues should be clear and concise.
-
-* Issues with compact reproducers, especially those which can be replicated on
- `the godbolt compiler explorer <https://godbolt.org>`_, are considered high
- quality.
+The minimum quality standards that any change must satisfy before being
+committed to the main development branch are:
+
+#. Code must adhere to the :doc:`LLVM Coding Standards <CodingStandards>`.
+
+#. Code must compile cleanly (no errors, no warnings) on at least one platform.
+
+#. Bug fixes and new features should `include a testcase`_ so we know if the
+ fix/feature ever regresses in the future.
+
+#. Pull requests should build and pass premerge checks. For first-time
+ contributors, this will require an initial cursory review to run the checks.
+
+#. Ensure that links in source code and test files point to publicly available
+ resources and are used primarily to add additional information rather than to
+ supply critical context. The surrounding comments should be sufficient to
+ provide the context behind such links.
+
+Additionally, the committer is responsible for addressing any problems found in
+the future that the change is responsible for. For example:
+
+* The code needs to compile cleanly and pass tests on all stable `LLVM
+ buildbots <https://lab.llvm.org/buildbot/>`_.
+
+* The changes should not cause any correctness regressions in the
+ `llvm-test-suite <https://github.com/llvm/llvm-test-suite>`_
+ and must not cause any major performance regressions.
+
+* The change set should not cause performance or correctness regressions for the
+ LLVM tools. See `llvm-compile-time-tracker.com <https://llvm-compile-time-tracker.com>`_
+
+* The changes should not cause performance or correctness regressions in code
+ compiled by LLVM on all applicable targets.
+
+* You are expected to address any `GitHub Issues
+ <https://github.com/llvm/llvm-project/issues>`_ that result from your change.
+
+Our build bots and `nightly testing infrastructure
+<https://llvm.org/docs/lnt/intro.html>`_ find many of these issues. Build bots
+will directly email you if a group of commits that included yours caused a
+failure. You are expected to check the build bot messages to see if they are
+your fault and, if so, fix the breakage. However, keep in mind that if you
+receive such an email, it is highly likely that your change is not at fault.
+Changes are batched together precisely because these tests are generally too
+expensive to run continuously for every change.
+
+Commits that violate these quality standards may be reverted (see below). This
+is necessary when the change blocks other developers from making progress. The
+developer is welcome to re-commit the change after the problem has been fixed.
.. _commit messages:
@@ -449,44 +423,6 @@ squashing and merging PRs.
For minor violations of these recommendations, the community normally favors
reminding the contributor of this policy over reverting.
-Post-commit responsibilities
-----------------------------
-
-There are many important qualities that LLVM aims for, but which we cannot
-afford to test for as part of our premerge pipeline. After landing a change,
-the committer is responsible for addressing any problems found in the future
-that the change is responsible for. Here are some of the issues that arise
-post-commit:
-
-* The code needs to compile cleanly and pass tests on all stable `LLVM
- buildbots <https://lab.llvm.org/buildbot/>`_.
-
-* The changes should not cause any correctness regressions in the
- `llvm-test-suite <https://github.com/llvm/llvm-test-suite>`_
- and must not cause any major performance regressions.
-
-* The change set should not cause performance or correctness regressions for the
- LLVM tools. See `llvm-compile-time-tracker.com <https://llvm-compile-time-tracker.com>`_
-
-* The changes should not cause performance or correctness regressions in code
- compiled by LLVM on all applicable targets.
-
-* You are expected to address any `GitHub Issues
- <https://github.com/llvm/llvm-project/issues>`_ that result from your change.
-
-Our build bots and `nightly testing infrastructure
-<https://llvm.org/docs/lnt/intro.html>`_ find many of these issues. Build bots
-will directly email you if a group of commits that included yours caused a
-failure. You are expected to check the build bot messages to see if they are
-your fault and, if so, fix the breakage. However, keep in mind that if you
-receive such an email, it is highly likely that your change is not at fault.
-Changes are batched together precisely because these tests are generally too
-expensive to run continuously for every change.
-
-Commits that violate these quality standards may be reverted (see below). This
-is necessary when the change blocks other developers from making progress. The
-developer is welcome to re-commit the change after the problem has been fixed.
-
.. _revert_policy:
Patch reversion policy
@@ -1521,66 +1457,4 @@ permission.
AI generated contributions
--------------------------
-LLVM's policy on AI-assisted tooling is fundamentally liberal -- We want to
-enable contributors to use the latest and greatest tools available. Our policy
-guided by two major concerns:
-
-1. Ensuring that contributions do not contain copyrighted content.
-2. Ensuring that contributions are not extractive and meet our `quality`_ bar.
-
-Artificial intelligence systems raise many questions around copyright that have
-yet to be answered. Our policy on AI tools is guided by our copyright policy:
-Contributors are responsible for ensuring that they have the right to contribute
-code under the terms of our license, typically meaning that either they, their
-employer, or their collaborators hold the copyright. Using AI tools to
-regenerate copyrighted material does not remove the copyright, and contributors
-are responsible for ensuring that such material does not appear in their
-contributions. Contributions found to violate this policy will be removed just
-like any other offending contribution.
-
-Recent improvements in AI-assisted tooling have made it easy to generate large
-volumes of code and text with little effort on the part of the contributor. This
-has increased the asymmetry between the work of producing a contribution, and
-the work of reviewing the contribution. In order to protect the time and
-attentional resources of LLVM project maintainers, the onus is on contributors
-to justify why their contributions are not extractive and meet our `quality`_
-bar. Contributors who repeatedly send low-quality contributions to our project
-will be subject to escalating moderation actions and eventually a project ban.
-
-This policy covers, but is not limited to, the following kinds of contributions:
-
-* Code, usually in the form of a pull request
-* RFCs or design proposals
-* Issues or security vulnerabilities
-* Comments and feedback on pull requests
-
-We encourage, but do not require, contributors making large changes to document
-the tools that they used as part of the rationale for why they believe their
-contribution has merit. This is similar in spirit to including a sed or Python
-script in the commit message when making large-scale changes to the project,
-such as updating the LLVM IR textual syntax.
-
-Here are some examples of contributions that demonstrate how to apply the
-principles of this policy:
-
-* `This PR <https://github.com/llvm/llvm-project/pull/142869>`_ contains a
- proof from Alive2, which is a strong signal of value and correctness.
-
-* This `generated documentation
- <https://discourse.llvm.org/t/searching-for-gsym-documentation/85185/2>`_ was
- reviewed for correctness by a human before being posted.
-
-**References:** Our policy was informed by experiences in other communities:
-
-* `Rust policy on burdensome PRs
- <https://github.com/rust-lang/compiler-team/issues/893>`_
-
-* `Seth Larson's post <https://sethmlarson.dev/slop-security-reports>`_ on slop
- security reports in the Python ecosystem
-
-* The METR paper `Measuring the Impact of Early-2025 AI on Experienced
- Open-Source Developer Productivity
- <https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/>`_.
-
-* `QEMU bans use of AI content generators
- <https://www.qemu.org/docs/master/devel/code-provenance.html#use-of-ai-content-generators>`_
+This section has moved into a :doc:`separate policy document <AIToolPolicy>`.
More information about the llvm-commits
mailing list