Add AI tools policy#13726
Conversation
This imports the AI tools guidelines from the CPython devguide (python/devguide#1778) verbatim, as a starting point for our own policy. The text is licensed under CC0-1.0. Source: https://github.com/python/devguide/blob/main/getting-started/ai-tools.rst
crates.io has no published "testing principles" document equivalent to the one this sentence references, so the guidance does not translate.
|
|
||
| ## Unacceptable uses | ||
|
|
||
| Maintainers may close issues and PRs that are not useful or productive, |
There was a problem hiding this comment.
So, I think it would be worth clarifying a bit more what "productive" means here, since it feels a little vague and it's not exactly clear what you're looking for. (I'm fine if you keep using the term "productive" as long as it's defined, just, maybe a few examples would help.)
Just guessing at what you mean, what might be worth mentioning:
- Typo fixes/aesthetic improvements that don't actually affect any public stuff: probably not helpful, can be submitted in large quantities by these tools
- Poorly justified changes, e.g. "I updated this page to be more readable" without any reasonable explanation
- Careless changes / author just wasn't paying attention and just clicked submit when they shouldn't have
There was a problem hiding this comment.
Thanks, I see where you're coming from but I'd actually prefer to leave "productive" deliberately vague.
To be honest I'm not sure all your examples land for me. Typo fixes for instance often seem fine. The kind of thing I'd see as unproductive is more like a PR where the author clearly doesn't understand what the LLM produced and is just acting as a transport medium between the model and the reviewer. But that's just one example, and I'd really rather leave it to maintainer judgment than enumerate it.
My worry with putting cases in the policy is that they get read as an exhaustive list. A PR that doesn't fit any listed category becomes harder to push back on ("but the policy doesn't say this counts"), and we'd be locking ourselves into whatever taxonomy we write down today. The point of this section, as I read it, is to give maintainers cover to use judgment on cases that don't fit cleanly into rules.
Happy to revisit if it turns out to be confusing in practice.
| Disclosure of the use of AI tools in the PR description is appreciated, | ||
| while not required. Be prepared to explain how the tool was used and what | ||
| changes it made. |
There was a problem hiding this comment.
So ultimately I don't expect crates.io to have a lot of PRs or issues so I think that ultimately this is just me giving advice that you're free to ignore. But at least from what I found, even projects which strongly support AI tools have been in favour of disclosing just so they know what they're dealing with, and I think that it's okay to have a hard rule with no punishments for forgetting it.
Like, I figure the rate of issues/PRs is so low that you have the time/resources to just individually talk to each person and figure out what they're working with anyway, but it can be helpful to ask for to see what people are using.
Just a few examples of other policies that feel relevant here:
There was a problem hiding this comment.
But at least from what I found, even projects which strongly support AI tools have been in favour of disclosing just so they know what they're dealing with, and I think that it's okay to have a hard rule with no punishments for forgetting it.
This would also be my preference.
I litigated this at some length within the Foundation when we were drafting our internal AI policy, so my apologies to @Turbo87 for the repeat, but the short version is that I believe that we should require disclosure for two primary reasons:
- Legal concerns. While I suspect our US-focused legal advice that LLM contributions are not subject to copyright will eventually end up being codified into international copyright law, this isn't even fully settled in the US, and we also have to operate in other, slower moving jurisdictions. If this does not end up being the result, we will need to be able to account for the origin of every contribution. Even if that outcome is unlikely, I think the minimal cost of requiring disclosure now is a small price to pay to make it easier to handle that eventuality.
- Review practicalities. While I don't think knowing LLMs have been used would meaningfully change how I review PRs from within the crates.io team, we do accept external contributions, and the sorts of things I expect to look for in review would change for a developer who used LLM assistance versus not, as would how I communicate with that contributor.
I don't want this to be some onerous process. I'd be happy with an Assisted-By or Co-Authored-By trailer in either the commit message or the PR description, much like the Linux kernel policy. But I do think it's important that we require this.
There was a problem hiding this comment.
It would be interesting to hear from counsel on the first point. I would expect to hear a mixed set of pros and cons for each choice — widespread disclosure seems likely to carry some risks too for the Project. Regarding the second point, the relevant comment in the Python discussions was this one — in short, reviewers need to assume LLM use anyway.
Disclosure has more than minimal cost:
- The transparency dilemma finding includes considerable data showing that, contrary to intuition, disclosure of LLM use erodes trust.
- Once primed about LLM use, people start to see LLM fingerprints that aren't actually there — we're creatures that see faces in clouds. Disclosure can increase the risk of false accusations of more LLM use than was disclosed.
- We're operating in an environment where people are actively shaming others who use LLMs. Highlighting one's use subjects one to the risk of this shaming.
Mandating disclosure has additional costs. It becomes something we need to enforce fairly and consistently. As part of a moderation policy, we'd be talking about banning people from the Project over this. If it turns out the policy is unenforceable and that people choose not to disclose due to these costs, then we'll have created a kind of policy fiction. That's not any good for us.
Similar to Python, we can encourage disclosure without incurring the costs that accompany mandating it.
There was a problem hiding this comment.
So, it is worth reiterating on the legal point that generally the result of using LLMs is the removal of copyright protections, not the addition of extra burdens, which does not matter given the extremely permissive license crates.io uses. It does matter for proprietary code and copyleft code, but for open source, permissively licensed work, it seems fine.
Additionally, it seems incredibly likely that if any copyright questions came up, e.g. someone was upset that code verbatim was used without authorisation, there would be ample time to fix the issue (removing the offending code) rather than these being immediate repercussions.
Most of the projects that I've seen be concerned with copyright issues are copyleft and thus specifically rely on copyright to enforce licencing, which just isn't the case here. So, while I do think there are other points to discuss, I don't think the legal point is particularly compelling here, which also matches the existing advice given by Foundation counsel on the matter.
There was a problem hiding this comment.
I think I do most of the PR reviews on crates.io at the moment (obviously excluding my own PRs…), and knowing whether AI was involved wouldn't change much how I review. The "explain your changes" requirement is already what I actually care about. For first-time contributors with zero context I agree disclosure can help, but that's a pretty different situation from someone opening a dozens of PRs each month.
On the legal point: the PSF landed on this exact wording without requiring disclosure. I don't know what their counsel actually said about it, so I'm only guessing, but I'd be a little surprised if a project that size shipped an AI policy without running it past their lawyers at some point. If that's roughly right, it makes me want to understand what's specifically different about our situation before treating the legal angle as a strong reason to go further than they did.
And I think Travis is right that disclosure has real downsides in the current climate. Adding a trailer to every PR also adds quite a bit of friction when LLM tooling is opening them, and getting that tooling to reliably add trailers is a whole separate problem.
That said, here are a few things I'd be happy to put in the policy, if it helps:
- Bump "appreciated, while not required" to "encouraged, especially from new contributors"
- Add something like "reviewers may ask about AI usage when it would help, and contributors should answer honestly"
Two other options to avoid the additional friction for regular contributors:
-
We can flip the framing: say explicitly that reviewers should assume AI may have been used, and make disclosure of non-use the optional opt-in. At this point the vast majority of recent crates.io PRs had LLM involvement and IMHO it's better to optimize for the 90% case.
-
One-time disclosure for regulars, recorded privately: contributors who use AI tooling regularly disclose it once (e.g. via a comment on a designated issue in the team's private ops guide repo) instead of repeating it on every PR. The record exists, so reviewers on the team have access and the legal/review-practicalities angle is covered, but the disclosure isn't sitting in a public list that anyone can scrape and turn into a target. For someone like me who opens a lot of PRs that drops the per-PR friction effectively to zero while still leaving the information available where it matters. First-time or external contributors would still get asked by a PR template or maybe by the reviewer.
There was a problem hiding this comment.
I mean, ultimately, I do think that the small number of contributions is more than sufficient to prefer an ad hoc method of explaining/disclosing since, like I said, you probably have the bandwidth to just talk to everyone individually about their changes. I think that encouraging more transparency is good, but if you think the downsides outweigh the upsides here, that's fair.
|
This is something I totally didn't even consider until now, but are there any other public repos managed by the crates.io team or is everything besides this just like, private infra accounts for controlling the actual deployed resources? I mostly ask since, this makes the most sense to just say "this is the policy of the crates.io team," but I don't actually know if there's anything else that would be controlled by you folks. |
There was a problem hiding this comment.
Approved is probably a strong word here, so I won't use it.
I have significant ethical concerns with the current state-of-the-art with regards to LLM assistants, and will not use them myself in any generative context. However, that is my own boundary, and I accept that everyone gets to make their own choice.
As discussed below, I think we should require disclosure. With that change, I would accept this policy.
| Disclosure of the use of AI tools in the PR description is appreciated, | ||
| while not required. Be prepared to explain how the tool was used and what | ||
| changes it made. |
There was a problem hiding this comment.
But at least from what I found, even projects which strongly support AI tools have been in favour of disclosing just so they know what they're dealing with, and I think that it's okay to have a hard rule with no punishments for forgetting it.
This would also be my preference.
I litigated this at some length within the Foundation when we were drafting our internal AI policy, so my apologies to @Turbo87 for the repeat, but the short version is that I believe that we should require disclosure for two primary reasons:
- Legal concerns. While I suspect our US-focused legal advice that LLM contributions are not subject to copyright will eventually end up being codified into international copyright law, this isn't even fully settled in the US, and we also have to operate in other, slower moving jurisdictions. If this does not end up being the result, we will need to be able to account for the origin of every contribution. Even if that outcome is unlikely, I think the minimal cost of requiring disclosure now is a small price to pay to make it easier to handle that eventuality.
- Review practicalities. While I don't think knowing LLMs have been used would meaningfully change how I review PRs from within the crates.io team, we do accept external contributions, and the sorts of things I expect to look for in review would change for a developer who used LLM assistance versus not, as would how I communicate with that contributor.
I don't want this to be some onerous process. I'd be happy with an Assisted-By or Co-Authored-By trailer in either the commit message or the PR description, much like the Linux kernel policy. But I do think it's important that we require this.
That's a good call out, but in this case, this repo is the only public repo owned by the crates.io team. I expect this policy — if approved — would also apply to our one private repo (our ops guide), but I'm not sure it's necessary to change this to explicitly include that. 🤷 |
|
Yeah, I figure that this kind of policy doesn't need to be clarified for private repos considering how it's mostly aimed at contributors who aren't on the team and thus don't have expectations set yet. So, with this being the only public crate for the repo and the repo receiving such a small amount of traffic externally as-is this policy is more than sufficient. I don't know if there are any crates.io team members who aren't Foundation staff but I feel that regardless, just deferring to Foundation policy for internal stuff would be sufficient. |
Quick correction on the scope claim: there are actually a few other public repos in the crates.io team's orbit. The authoritative list is in the team-api (https://team-api.infra.rust-lang.org/v1/repos.json), but off the top of my head:
For the repos where the policy is actually relevant (
That way we don't have to manage copies, and as the team's repo list changes the policy follows automatically. |
|
Specifically for Might poke around later to see if the current infra we have allows automatically doing this via the Edit: It appears that this is done manually: https://github.com/rust-lang/team/blob/main/repos/rust-lang/crates.io-index.toml So, I'll open a thread on Zulip about it. |
5 participants
This PR proposes adopting the CPython devguide's AI tools policy as crates.io's own, as
docs/AI-TOOLS.md(with one Python-specific testing sentence dropped). It is linked fromCONTRIBUTING.mdandAGENTS.md.The CPython policy puts responsibility for content on the submitter, requires contributors to be able to explain their changes, and doesn't try to ban AI tooling outright. That matches how things are already done in this project and seems a reasonable starting point.
Project-wide AI policy for rust-lang is still being debated in two open RFCs (neither close to consensus), with a separate
rust-lang/rust-scoped policy that explicitly excludes crates.io. If a project-wide policy is later adopted, we can align with it.Open to feedback on whether this is the right policy and whether anything should be adjusted before merging.
Related
rust-lang/rustrust-forge#1040