[docs] Strengthen our quality standards and connect AI contribution policy to it

llvm/docs/AIToolPolicy.md

@@ -0,0 +1,154 @@
+# 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. 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][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, and AI tools tend
+  to generate large contributions. We encourage new contributors to keep their
+  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
+  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: <name of code assistant>. 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.
+
+[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:
+
+- Code, usually in the form of a pull request
+- RFCs or design proposals
+- Issues or security vulnerabilities
+- Comments and feedback on pull requests
+
+
+## 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! We see the act
+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 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
+from the book [Working in Public][public] by Nadia Eghbal:
+
+[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
+> 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.
+
+## Handling Violations
+
+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
+    our developer policy on AI-generated contributions:
+    http://llvm.org/docs/AIToolPolicy.html
+
+Other reviewers should use the label prioritize their review time.
+
+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.
+
+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
+
+Here are some examples of contributions that demonstrate how to apply
+the principles of this policy:
+
+- [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
+
+Our policy was informed by experiences in other communities:
+
+- [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][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

llvm/docs/DeveloperPolicy.rst

@@ -1457,23 +1457,4 @@ permission.
 AI generated contributions
 --------------------------
 
-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.
-
-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.
+This section has moved into a :doc:`separate policy document <AIToolPolicy>`.

llvm/docs/Reference.rst

@@ -9,6 +9,7 @@ LLVM and API reference documentation.
 .. toctree::
    :hidden:
 
+   AIToolPolicy
    Atomics
    BitCodeFormat
    BlockFrequencyTerminology