AI Usage Policy / AI Usage Dislosure?

[Sevans711]

Should uxarray have an AI Usage Policy? Also, should uxarray add an AI Usage Disclosure section or checklist item to the default github PR form template? (See also some recent work to improve that form: #1608)

There are many good examples online already. Pasting some of them below to help provide an easier starting point for discussion.

Example: xarray

xarray added an AI usage policy a few months ago (pydata/xarray#11126), as well as a section on the PR form:

### AI Disclosure

<!--- Please review our AI & contribution guidelines: https://docs.xarray.dev/en/stable/contribute/ai-policy.html.
    Remove this section if your PR does not contain AI-generated content. --->

- [ ] This PR contains AI-generated content.
  - [ ] I have tested any AI-generated content in my PR.
  - [ ] I take responsibility for any AI-generated content in my PR.
    <!--- If you used AI to generate code, please specify the tool used and the prompt below. --->
    Tools: {e.g., Claude, Codex, GitHub Copilot, ChatGPT, etc.}

Example: numpy

numpy's PR form includes:

#### AI Disclosure
<!-- If AI was used in the preparation of this pull request, please disclose
the tool(s) used, how they were used, and specify what code or text is AI generated.
If no AI tools were used, please write "No AI tools used" in this section. Read our
policy on AI generated code at
https://numpy.org/devdocs/dev/ai_policy.html.

In particular, all interaction is to be done by humans, including submission of PRs.
-->

Example: holoviews

holoviews PR form includes the following:

## AI Disclosure
<!-- Delete this section if AI was not used, else specify the tool/model
    (e.g. Cursor + Sonnet 4.6, Claude Code + Opus 4.6, ChatGPT) and briefly describe how it was used.
    Failure to disclose AI usage may result in a ban. -->

Tool & Model:
Usage:

- [ ] I have tested all AI-generated content in my PR.
- [ ] I take responsibility for all AI-generated content in my PR.

[cmdupuis3]

Looks fine to me. I was thinking of adding an "I actually read it" line, but that might short-lived. For my own stuff, agentic dev usually goes well as long as you have it hooked into the tests, which we should be doing anyway.

[erogluorhan]

This is a great start to this! Even if incomplete, we should have something in place. Will think more about this soon.

[Sevans711]

Adding the netcdf AI policy as an example which could be considered here as well:
https://github.com/Unidata/netcdf-c/blob/main/.github/AI_GUIDELINES.md

[kafitzgerald]

If you want a broader list, this might be useful (though overwhelming): https://github.com/melissawm/open-source-ai-contribution-policies

This section on agentic AI from the Scientific Python Development Guide might also be of interest: https://learn.scientific-python.org/development/guides/ai/

FWIW, the "Extractive Contributions" section of the netCDF AI guidelines was what prompted Ryan to share that with me. I'm not sure it's exactly right for our projects, but hits on some concerns of mine.

And it looks like GitHub is working on some features to help address related issues: https://github.blog/open-source/maintainers/how-pull-request-limits-are-cutting-down-the-noise/

[rajeeja]

I think adding a lightweight checklist now (holoviews-style) makes sense — cheap to add, easy to revise. Given how fast this space moves, I'd treat the wording as a living doc rather than something to get "right" upfront. Can revisit in a few months once we see how it plays out in practice.

[erogluorhan]

@rajeeja 's suggestion makes sense to me. Start with adding an AI disclosure into PR checklist, which can be something in between xarray's and holoviews' (Would asking about the exact AI tool and prompts as in xarray's be discouraging for contributors?).

I'd also find it useful to have a pretty lightweigt AI policy doc in our repo that could be referred to from within the PR disclosure (Something like xarray's or maybe even lighterweight).

[Sevans711]

I do think asking about the exact AI tool would be discouraging, and asking about prompts used would be especially discouraging.

It's much easier to say "Claude" than to look up / recall which versions of Claude were used. I'm sure it would also take me a while to figure out what version of Github Copilot I'm using. Maybe we could just ask for tools used (e.g. "Claude, Github Copilot") and say "please include model number if you know it, e.g. Claude + Opus 4.6" but not require the version numbers if they aren't known?

Asking for prompts used would be especially discouraging; some prompts are multi-paragraphs of context and some are me asking probably-silly questions that I don't necessarily want everyone to know I didn't know the answer to beforehand. Also, I have no idea how I would say what the prompts are for Github Copilot's inline completions…. I do think it's not asking too much to require a brief description of how the tools were used though, similarly to what holoviews is doing.

Thank you for opening an issue on this - seeing that github didn't mention it automatically in this discussion, I'm putting a reference to it here: #1630

[cmdupuis3]

Asking for prompts would be pretty discouraging, I keep mine super casual so I'd be put off personally.

Also, if you have claude commit, rather than commiting yourself, it will stamp it with the model name and number in the commit message.

[cmdupuis3]

So here's a fresh situation:

Occasionally with Claude I find an incidental bug or issue outside the scope of what I'm actually doing. I'm wondering how we should approach filing issues like that?

[erogluorhan]

Do your human assessment of it and if it looks legit, go create a bug would be my choice.

[rljacob]

Same. You could mention in the issue "found with Claude" or whatever.

[Sevans711]

Agreeing with comments above, it makes sense to add bug reports so that these things can get fixed.

In terms of AI disclosure, I agree you definitely could mention it. I don't think it should be required, but should it be encouraged? We could update the default issue report forms accordingly, if people want.

If this is more of a question of "is the bug significant enough to report", I think it's best to feel encouraged to just post it, once you've verified it is really a bug. If this leads to too many issue reports, someone could follow up to ask you to slow down on issue reports, but until then it's probably safe to assume it's not too many.