From b9aaea935a807f57d6041166357bc2df69257dec Mon Sep 17 00:00:00 2001 From: Reid Kleckner Date: Fri, 18 Jul 2025 16:28:44 -0700 Subject: [PATCH 1/9] [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 `_. - -#. 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 `_. #. 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 +`_ 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 `_ 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 `_ 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 `_ contains a + proof from Alive2, which is a strong signal of value and correctness. + +* This `generated documentation + `_ 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 + `_ + +* `Seth Larson's post `_ on slop + security reports in the Python ecosystem + +* The METR paper `Measuring the Impact of Early-2025 AI on Experienced + Open-Source Developer Productivity + `_. + +* `QEMU bans use of AI content generators + `_ From 8f861a0f42695ace9c78e322d48537f861615381 Mon Sep 17 00:00:00 2001 From: Reid Kleckner Date: Wed, 20 Aug 2025 10:52:12 -0700 Subject: [PATCH 2/9] 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 `_. - -#. 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 -`_ 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 `_ 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 `_. + +* 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 + `_) 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 `_, 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 `_ + 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 `_ that - result from your change. +* You are expected to address any `GitHub 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 Date: Mon, 25 Aug 2025 14:48:38 -0700 Subject: [PATCH 3/9] 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 `_. * 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. + LLVM tools. See `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 `_ 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 +`_ 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 Date: Mon, 25 Aug 2025 16:22:23 -0700 Subject: [PATCH 4/9] 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 Date: Tue, 2 Sep 2025 14:26:54 -0700 Subject: [PATCH 5/9] 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 Date: Tue, 2 Sep 2025 15:51:26 -0700 Subject: [PATCH 6/9] 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 `_ 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 `_. - -* 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 - `_) 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 `_, 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 `. + +#. 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 `_. + +* 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. See `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 + `_ that result from your change. + +Our build bots and `nightly testing infrastructure +`_ 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 `_. - -* 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. See `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 - `_ that result from your change. - -Our build bots and `nightly testing infrastructure -`_ 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 `_ contains a - proof from Alive2, which is a strong signal of value and correctness. - -* This `generated documentation - `_ 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 - `_ - -* `Seth Larson's post `_ on slop - security reports in the Python ecosystem - -* The METR paper `Measuring the Impact of Early-2025 AI on Experienced - Open-Source Developer Productivity - `_. - -* `QEMU bans use of AI content generators - `_ +This section has moved into a :doc:`separate policy document `. From 77071edf80fc8317eaef1d695adb1647680b1bc5 Mon Sep 17 00:00:00 2001 From: Reid Kleckner Date: Wed, 1 Oct 2025 15:30:17 -0700 Subject: [PATCH 7/9] Incorporate the Fedora policy, indicate it carries a CCA license, retain attribution, and add a point about contribution size --- llvm/docs/AIToolPolicy.md | 153 ++++++++++++++++++++++---------------- 1 file changed, 87 insertions(+), 66 deletions(-) diff --git a/llvm/docs/AIToolPolicy.md b/llvm/docs/AIToolPolicy.md index c522fdcaec4c1..288ad30f3f780 100644 --- a/llvm/docs/AIToolPolicy.md +++ b/llvm/docs/AIToolPolicy.md @@ -1,46 +1,68 @@ # 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 -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: +enable contributors to use the latest and greatest tools available. However, +human oversight remains critical. **The contributor is always the author and is +fully accountable for their contributions.** + +* **You are responsible for your contributions.** AI-generated content must be + treated as a suggestion, not as final code or text. It is your responsibility + to review, test, and understand everything you submit. Submitting unverified or + low-quality machine-generated content (sometimes called "[AI + slop](https://simonwillison.net/2024/May/8/slop/)") creates an + unfair review burden on the community and is not an acceptable contribution. + Contributors should review and understand their own submissions before asking + the community to review their code. + +* **Start with small contributions:** Open source communities operate on trust + and reputation. Reviewing large contributions is expensive. AI tools have a + tendency to generate large contributions that are expensive to review. We + encourage new contributors to keep their first contributions small until they + build personal expertise and maintainer trust before taking on larger + changes. + +* **Be transparent about your use of AI.** When a contribution has been + significantly assisted by an AI tool, we encourage you to note this in your + pull request description, commit message, or wherever authorship is normally + indicated for the work. For instance, use a commit message trailer like + Assisted-by: . This transparency helps the community + develop best practices and understand the role of these new tools. + +* **LLVM values Your Voice.** Clear, concise, and authentic communication is + our goal. Using AI tools to translate your thoughts or overcome language + barriers is a welcome and encouraged practice, but keep in mind, we value your + unique voice and perspective. + +* **Limit AI Tools for Reviewing.** As with creating code, documentation, and + other contributions, reviewers may use AI tools to assist in providing + feedback, but not to wholly automate the review process. Particularly, AI + should not make the final determination on whether a contribution is accepted + or not. The same principle of ownership applies to review comment + contributions as it does to code contributions. + +This policy extends beyond code contributions and includes, 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 +## Extractive Changes 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: +lot of maintainer time and energy to review those contributions! We see the act +of sending low-quality unreviewed contributions to the LLVM project as +"extractive." It is an attempt to extract work from the LLVM project community +in the form of review comments and mentorship, without the contributor putting +in comensurate effort to make their work worth reviewing. + +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][public] by Nadia Eghbal: -[1]: https://press.stripe.com/working-in-public +[public]: 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 @@ -59,15 +81,12 @@ 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. +## Handling Violations -If a maintainer judges that a contribution is extractive (i.e. it is generated -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: +If a maintainer judges that a contribution is *extractive* (i.e. it is +generated with tool-assistance or simply requires significant revision), 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 @@ -76,33 +95,27 @@ and refrain from further engagement: 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. +If a contributor responds but doesn't make their change meaningfully less +extractive, maintainers should escalate to the relevant moderation or admin +team for the space (GitHub, Discourse, Discord, etc) to lock the conversation. + +## 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. ## Examples @@ -119,12 +132,20 @@ the principles of this policy: 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) +- [Fedora Council Policy Proposal: Policy on AI-Assisted Contributions (fetched + 2025-10-01)][fedora]: Some of the text above was copied from the (very good!) Fedora + project policy proposal, which is licensed under the [Creative Commons + Attribution 4.0 International License][cca]. This link serves as attribution. +- [Rust draft policy on burdensome PRs][rust-burdensome] +- [Seth Larson's post][security-slop] 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) + Open-Source Developer Productivity][metr-paper]. +- [QEMU bans use of AI content generators][qemu-ban] + +[fedora]: https://communityblog.fedoraproject.org/council-policy-proposal-policy-on-ai-assisted-contributions/ +[cca]: https://creativecommons.org/licenses/by/4.0/ +[rust-burdensome]: https://github.com/rust-lang/compiler-team/issues/893 +[security-slop]: https://sethmlarson.dev/slop-security-reports +[metr-paper]: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ +[qemu-ban]: https://www.qemu.org/docs/master/devel/code-provenance.html#use-of-ai-content-generators From a8ed845a842c3766c9a29030f2374fd871043aa7 Mon Sep 17 00:00:00 2001 From: Reid Kleckner Date: Wed, 1 Oct 2025 15:40:20 -0700 Subject: [PATCH 8/9] More minor edits --- llvm/docs/AIToolPolicy.md | 36 +++++++++++++++++++----------------- 1 file changed, 19 insertions(+), 17 deletions(-) diff --git a/llvm/docs/AIToolPolicy.md b/llvm/docs/AIToolPolicy.md index 288ad30f3f780..37fe8b63747ee 100644 --- a/llvm/docs/AIToolPolicy.md +++ b/llvm/docs/AIToolPolicy.md @@ -9,20 +9,18 @@ fully accountable for their contributions.** treated as a suggestion, not as final code or text. It is your responsibility to review, test, and understand everything you submit. Submitting unverified or low-quality machine-generated content (sometimes called "[AI - slop](https://simonwillison.net/2024/May/8/slop/)") creates an - unfair review burden on the community and is not an acceptable contribution. - Contributors should review and understand their own submissions before asking - the community to review their code. + slop][ai-slop]") creates an unfair review burden on the community and is not + an acceptable contribution. Contributors should review and understand their own + submissions before asking the community to review their code. * **Start with small contributions:** Open source communities operate on trust - and reputation. Reviewing large contributions is expensive. AI tools have a - tendency to generate large contributions that are expensive to review. We - encourage new contributors to keep their first contributions small until they - build personal expertise and maintainer trust before taking on larger - changes. + and reputation. Reviewing large contributions is expensive, and AI tools tend + to generate large contributions. We encourage new contributors to keep their + first contributions small until they build personal expertise and maintainer + trust before taking on larger changes. * **Be transparent about your use of AI.** When a contribution has been - significantly assisted by an AI tool, we encourage you to note this in your + significantly generated by an AI tool, we encourage you to note this in your pull request description, commit message, or wherever authorship is normally indicated for the work. For instance, use a commit message trailer like Assisted-by: . This transparency helps the community @@ -40,6 +38,8 @@ fully accountable for their contributions.** or not. The same principle of ownership applies to review comment contributions as it does to code contributions. +[ai-slop]: https://simonwillison.net/2024/May/8/slop/ + This policy extends beyond code contributions and includes, but is not limited to, the following kinds of contributions: @@ -53,10 +53,10 @@ to, the following kinds of contributions: Sending patches, PRs, RFCs, comments, etc to LLVM, is not free -- it takes a lot of maintainer time and energy to review those contributions! We see the act -of sending low-quality unreviewed contributions to the LLVM project as +of sending low-quality, un-self-reviewed contributions to the LLVM project as "extractive." It is an attempt to extract work from the LLVM project community in the form of review comments and mentorship, without the contributor putting -in comensurate effort to make their work worth reviewing. +in comensurate effort to make their contribution worth reviewing. 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 @@ -122,11 +122,13 @@ just like any other offending contribution. 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. +- [This PR][alive-pr] contains a proof from Alive2, which is a strong signal of + value and correctness. +- This [generated documentation][gsym-docs] was reviewed for correctness by a + human before being posted. + +[alive-pr]: https://github.com/llvm/llvm-project/pull/142869 +[gsym-docs]: https://discourse.llvm.org/t/searching-for-gsym-documentation/85185/2 ## References From ed524ff7af2b00abc3b9d883b5880d865d69593f Mon Sep 17 00:00:00 2001 From: Reid Kleckner Date: Wed, 1 Oct 2025 16:01:22 -0700 Subject: [PATCH 9/9] Add objective guideline of 150 additional lines of code --- llvm/docs/AIToolPolicy.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/llvm/docs/AIToolPolicy.md b/llvm/docs/AIToolPolicy.md index 37fe8b63747ee..f760e6ec3620d 100644 --- a/llvm/docs/AIToolPolicy.md +++ b/llvm/docs/AIToolPolicy.md @@ -16,7 +16,8 @@ fully accountable for their contributions.** * **Start with small contributions:** Open source communities operate on trust and reputation. Reviewing large contributions is expensive, and AI tools tend to generate large contributions. We encourage new contributors to keep their - first contributions small until they build personal expertise and maintainer + first contributions small, specifically below 150 additional lines of + non-test code insertions, until they build personal expertise and maintainer trust before taking on larger changes. * **Be transparent about your use of AI.** When a contribution has been