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