Add Spack AI usage policy - #7
Conversation
Signed-off-by: Gregory Becker <becker33@llnl.gov> Assisted-by: Claude Fable 5
wdconinc
left a comment
wdconinc
left a comment
There was a problem hiding this comment.
(minor) I might have included a reference to Nadia Eghbal's Working in Public where I think the terminology of "extractive contributions" was first introduced.
|
I think this policy is succinct, clear, and covers the bases. |
| @@ -0,0 +1,26 @@ | |||
| Spack AI Usage Policy | |||
|
|
|||
| 1. Extractive contributions | |||
There was a problem hiding this comment.
Formatting doesn't look great at the moment: https://github.com/spack/governance/blob/ai-policy-minimal/AI-POLICY.md
I think the following paragraphs need to be indented one more space, or just convert the list to section headers like ###
|
|
||
| 1. Extractive contributions | ||
|
|
||
| AI tools lower the cost of producing plausible-looking contributions. At best, the maintainer cost to review these contributions is mostly unchanged. Without effort from the user, AI-generated contributions can be verbose and difficult for maintainers to review. |
There was a problem hiding this comment.
Should we clarify that just because something looks plausible or succinct doesn't mean it's correct? Hallucinated code is the most extractive of all.
| - You are responsible for everything you submit, however it was produced. | ||
| - Understand every component of your contribution well enough to discuss and revise technical details. | ||
| - Maintainers may close any PR or issue they judge to be extractive. | ||
| - Contributors who repeatedly submit extractive contributions will be suspended or banned. |
There was a problem hiding this comment.
Does this include maintainers? 😉
Seriously though, some of my maintainers have violated this policy many times already.
| Every contribution must have a human author of record. AI tools may not be listed as authors or co-authors. | ||
|
|
||
| - The human author's Signed-off-by: (DCO) certifies that they have the right to submit the work. | ||
| - If you are not claiming full authorship of your AI-assisted contribution, use an Assisted-by: commit trailer to give credit, e.g. Assisted-by: Claude Fable 5 |
There was a problem hiding this comment.
I would broaden this. Even if you want to "claim" full authorship, if something is AI-assisted, that should be documented.
I would also propose a bot that adds an "AI-assisted" label to all PRs that have this commit trailer. This would help me decide which PRs to review and which to ignore. Every maintainer should have the right to decide whether or not to review AI-assisted PRs.
There was a problem hiding this comment.
I'm not willing to add contribution friction over whether someone properly credits AI on a PR that is already below the threshold of originality, and I want to make sure that our policy doesn't sign us up to enforce something that is painful for no benefit.
There was a problem hiding this comment.
What about something above the threshold of originality?
There was a problem hiding this comment.
Personally? I don't think it matters, and would not want to require a new commit for them to fix it. Assisted-by doesn't mean the author can't hold copyright, and it doesn't provide us anything to go by in determining whether they can. The only context in which it matters to me is something over the threshold for which they didn't make substantial enough changes to hold copyright. Squashing commits only adds to the confusion -- we will list an entire PR as AI-assisted because the contributor used AI to help write unit tests.
From a project policy perspective: I think we should wait and implement whatever LF eventually determines to be our legal requirements, but I don't think we know what that is yet and we're just guessing at it.
I also think making a policy that we can't enforce is counterproductive to maintaining the community atmosphere that we want. We have enough trouble merging things in a timely manner as-is.
There was a problem hiding this comment.
From a project policy perspective: I think we should wait and implement whatever LF eventually determines to be our legal requirements, but I don't think we know what that is yet and we're just guessing at it.
Agreed with this. Does our LF contact have any contact with LF legal? Would be nice to know a timeline.
There was a problem hiding this comment.
I can ask @christopherclark about it on HPSF slack, I don't know whether he gets notifications from here.
There was a problem hiding this comment.
Apparently we have a lot of leeway to set our own policy, at least for now: https://www.linuxfoundation.org/legal/generative-ai
|
|
||
| 3. Human interaction | ||
|
|
||
| Review comments and questions are addressed to you, not your tooling. You may use AI to help draft a reply, but a human must understand and post it. |
There was a problem hiding this comment.
Should this apply to issue/PR/discussion descriptions as well? This was divisive in my other org. I'm on the fence, but a verbose description is definitely extractive (takes me longer to read than it took the author to write).
4 participants
The goal of this policy is to be lightweight and neutral. AI is a tool, and like all tools it can be used well or poorly. We aim to prohibit the most antisocial uses of AI without being unfriendly to people using it effectively.
Summary:
Assisted-by: Claude Fable 5