Incorporate the Fedora policy, indicate it carries a CCA license, retain attribution, and add a point about contribution size

Author: rnk

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: <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.
+
+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