Add an AI policy

[adamjstewart]

As discussed in the last TSC meeting, I am proposing a moderate AI policy to help guard against AI slop. Spack hasn't been impacted much yet, but the wave is coming. This current draft is the same as TorchGeo's AI policy, but can and should evolve to deal with the specifics of Spack. Please provide feedback and let me know if there is anything you find prohibitively restrictive or too loose.

[haampie]

As a contributor, I don't want to do this. It's just busy work.

[tgamblin]

are you opposed to using Assisted-by: on commits?

[adamjstewart]

This would be included in the default PR template, so it shouldn't take longer than 10 ms to click an option.

Open source involves a lot of busy work: DCO, PEP-8, being kind. These expectations aren't in place to make you suffer, they are necessary for strangers on the internet to work together on the same piece of code without conflict.

For the sake of my mental health, I no longer review AI-assisted or AI-generated code. A disclosure template saves me an enormous amount of time so I can unsubscribe and ignore most PRs. I think every maintainer should have the right to decide how valuable their time is.

[tgamblin]

Note that we do not (yet) have the same extent of AI slop contributions that TorchGeo does (at least according to @adamjstewart). I don't mind the checkbox though it might be nice if we just had an assigned by spackbot when it notices Assisted-by: commits... and leave it at that. Would that work?

[adamjstewart]

P.S. I would be fine with a bot that extracts "Assisted-by" from commit messages and adds a PR label. As long as it's clear how much time I should invest as a reviewer.

[becker33]

I would rather check a box in the PR than have to add Assisted-by on every commit. I don't let the model commit on my behalf, and I don't (yet) know of a way to automatically add the Assisted-by block from the CLI.

[haampie]

I create the majority of my PRs with gh pr create which uses the commit message as the title / body; so I typically spend time on the commit message and only seconds on submitting the pr, except maybe deleting Signed-Off-By which I had to previously add with commit -s, which is already a form of busy work.

The git commit -s is a habit, removing it from the PR description is something I sometimes forget, yet another step in this process is just too much. The people reviewing my PRs don't benefit from the AI disclosure message.

As a reviewer, I can judge quickly from the code if it was AI-generated or not.

[haampie]

Also, I sometimes do not contribute to other projects that require too many steps to contribute: having to subscribe to a mailing lists, create an account, sign something, create an issue before a pr, ... ;) This reminds me of statistics from Google where increasing page load time by x seconds increases bounce rates by y%.

The extra steps required for contribution might negatively affect useful "drive by" PRs. Ultimately people submitting well-intended PRs now have to take another step, whereas the bots that automatically open PRs will ignore the [x] anyways (they likely use gh pr create too).

[haampie]

And "but you can automate Assisted-By" is not helpful for the once-every-so-many-months contributor

[adamjstewart]

At least according to Gemini (oh the irony), it's pretty easy to configure Claude to use Assisted-by instead of Co-authored-by:

{
  "attribution": {
    "commit": "Assisted-by: Claude Code",
    "pr": "Assisted-by: Claude Code"
  }
}

Would we be willing to compromise on the following?:

1. Disallow bots in Signed-off-by and Co-authored-by, add a CI DCO check for this
2. Require disclosure in one of two possible forms:
   a. Assisted-by in DCO, or
   b. PR template checkbox
3. Add a bot to collate these two disclosure forms into a label tag

[haampie]

I cannot get behind this policy. It's not neutral, and I believe it should be. I also don't think it will age well.

Personally I don't want to do the unnecessary busy work of disclosing use of AI.

Otherwise I'd like to change phrasing throughout so it doesn't suggest that "AI is bad". I would drop all this:

• The use of colors green/orange/red. The majority of devs fall into 🟠 which carries the meaning of warning/caution.
• Use of terms that "criminalize" use of AI: first-time offense, second-time offense, penalties, ...
• The masochistic "proof of suffering" when opening issues. It should be low-effort to open an issue, we never asked anybody to invest time in it, other than providing something reproducible to make it more likely that the issue is addressed.
• Apologizing for mistakes
• Certain sections feel paternalising: "it is unlikely that you will be able to fully grasp the AI implementation". Even if you drop the curious "will be able to", I don't think it matches reality. There are AI generated pieces of code understood by people, who judge that it is unnecessary to make changes.

@adamjstewart I see AI as a tool, and I would encourage to read your own writing where you replace "AI" with "vim", "emacs" or "gdb" and see how it reads, then you understand how I feel about it ;).

[adamjstewart]

FYI, I'm starting to rethink the TorchGeo AI policy. As dozens of people have been trying to tell me for months, AI-assisted isn't the problem, AI slop is. I would like to make the policy more friendly to good uses of AI and more strict about "extractive contributions". Will work on redesigning the TorchGeo policy to reflect this, but I think the existing changes to this PR are already in the right direction.