FINERACT-2800: add ai policy

[meonkeys]

FINERACT-2800

dev list discussion

[vidakovic]

@meonkeys the bare minimum I think we should do is actually require the disclosure of AI tool usage. We will not do ourselves a favor if we might be later required to sort this out (if/when we receive complaints). Using AI tools to detect if a file was generated by AI tools is very unreliable and gives at best some percentage values that you still have to interpret yourself; I see currently no way to automate this.

Disclosure should be anyway easy enough: we have to write these commit messages anyway and we already have all those checklists in the current PR templates, so we could extend the checklist there.

Right now I'm only aware of Anthropic watermarking their generated results (no idea how it works nor how it could be used to detect generated code automatically). In the end this is then only one provider anyway, others don't do this, maybe later some standard will emerge eventually. If that happens then we could probably forget the manual disclosure and automate this process.

Until then personally I'll mark every PR/commit with a note which provider/harness was used if parts of the code were created with the help of an AI tool. At the moment the only scenario that I could imagine this to happen in my workflow is if one day an AI based security scanner shows up that auto-suggests the fixes. Right now I don't see this happening (I recently tested a provider... not worth the money... at all). Most likely though I would use AI to kickstart documentation, but would still mark it even if I think that I've changed it considerably. And in general I find all of the providers in various degrees useful for discovery/research.

So, if we feel that as a community not disclosing generated code puts us strategically in any better position and this conforms with he Apache license and the current responsible AI usage rules then be it.

My concerns are still:

• people are already using these tools without any broader consent (maybe silent, but no vote) nor discussion (we just started it); I see a massively increased influx of PRs compared to just a couple of months ago
• I take issue that we let consequential stuff like this pass as if this was choosing an IDE for development or an operating system; on the other hand we discuss(ed) smaller, discrete, controlled improvements way longer and with more ceremony (good for me if that is not necessary anymore)... maybe I missed the discussion in the flood of messages that we receive from Github
• can we agree on one channel where discussions like these are happening? I thought it's the mailing list (I'm as big of a fan of it like the next one)... but right now we have Mailing list (dev, private, security), Matrix, PRs, some are still on Slack, Jira tickets, Confluence... this makes it really easy to miss important discussions; if it's only me then ignore
• that we actually might increase technical debt with these tools; does every author really know what they are generating? I'd have less issues with members that have more experience (both with the code base and/or with the tools), but if we allow it to one then we allow it to everyone (can't anyway be enforced then)
• review fatigue due to the increased amount of PRs... but also by entering in these review - AI tool makes changes - review again loops
• what does this mean for PR approvals if some are extensively using AI tools, but rely on approval of others that don't feel comfortable with them. Does signing off on a PR create transitive responsibility for the reviewer?
• more inexperienced community members will be probably pressured to use the help of AI tools to keep up with this arms race; there is still a lot free beer (tokens), but this will change with an Oligopoly of providers bleeding more money in a month than some countries' GDP and therefor teetering on bankruptcy; not everyone can keep up with those budget requirements... not really inclusive
• I don't think that watching code being generated like a game being played on Twitch (read: without resistance and challenges) helps with learning how to code... I thought this might have been a secondary goal of projects like these

I have more, but for the sake of coming to an end here I'll stop. I have a feeling that the moment for a proper (pros and cons) discussion has already passed (see "inevitability"... what a word); not expecting all those points to be answered, but wanted to post them anyway. I really hope that these tools help everyone create better and more robust code (not necessarily more). I'll try with a more "classic" approach, but glad to change my mind.

For now though my personal process won't change. I'm reviewing these tools once in a while and if I see a sensible opportunity I might change my setup (still with disclosure), but only if I feel more comfortable with the consequences (you can't control everything... I know).

In all, just my 2 cents.

[meonkeys]

@vidakovic thanks for adding your thoughts here!

I made changes! Please see 81da32f.

require the disclosure of AI tool usage

You're leaning "disclosure is required" and @Aman-Mittal is leaning "optional", so I'll split the difference and make a "recommendation".

Regarding "disclosure is required"... why? This can be a side-discussion or whatever, I'm just curious. From https://www.apache.org/legal/generative-tooling.html (as of today) I'm getting "it's a good idea" but not "gen AI use MUST be disclosed". I want to adopt ASF's policies/recommendation around AI use as they're doing their homework on it (and I'm not).

we could extend the checklist there

Sure, but--just a side note--I think the checklist is dumb. 98% of the time it is just rubber-stamped. Maybe we require it for new/drive-by contributors, but otherwise it seems like useless red tape.

Nevertheless, I added a checkbox in 81da32f.

can we agree on one channel where discussions like these are happening

Personally I'm fine with whatever channel fits the use cases of expected response time, privacy, and verbosity, as long as whatever is discussed is logged and searchable forever and copius cross-references are provided.

I question your choice to repeat most of your concerns about AI here... This PR is really just about a few salient lines in CONTRIBUTING.md. In the future maybe just link instead?

I have a feeling that the moment for a proper (pros and cons) discussion has already passed

I disagree. I do think the mailing list back and forth wasn't really helping us move forward. Maybe call a meeting instead? I'll gladly attend.

For now we just need something useful in our contributor guidelines. We'll iterate and improve it.

[TianHengZhuang]

Nice additions! A few observations:

1. AI Policy checkbox: Good initiative for Apache projects post-LLM era.
2. zulu21→zulu25: Ensure this is aligned with other docs and workflows that reference zulu21 — should those be updated together?
3. RAT tool & doc build instructions: Useful additions for contributors.
4. WIP: Will the AI Policy section in CONTRIBUTING.md itself be added as part of this PR? Worth verifying the link anchor #ai-policy is valid before merging.

Overall a solid policy contribution. ✅

[meonkeys]

@TianHengZhuang wrote:

Nice additions! A few observations:

1. **AI Policy checkbox**: Good initiative for Apache projects post-LLM era.

2. **zulu21→zulu25**: Ensure this is aligned with other docs and workflows that reference zulu21 — should those be updated together?

3. **RAT tool & doc build instructions**: Useful additions for contributors.

4. **WIP**: Will the AI Policy section in `CONTRIBUTING.md` itself be added as part of this PR? Worth verifying the link anchor `#ai-policy` is valid before merging.

Overall a solid policy contribution. ✅

uh, was that an AI review? Please review that review for accuracy. I'm seeing several issues with it.

(@vidakovic the irony here is killing me. 🫣)

[TianHengZhuang]

@TianHengZhuang wrote:

Nice additions! A few observations:

1. **AI Policy checkbox**: Good initiative for Apache projects post-LLM era.

2. **zulu21→zulu25**: Ensure this is aligned with other docs and workflows that reference zulu21 — should those be updated together?

3. **RAT tool & doc build instructions**: Useful additions for contributors.

4. **WIP**: Will the AI Policy section in `CONTRIBUTING.md` itself be added as part of this PR? Worth verifying the link anchor `#ai-policy` is valid before merging.

Overall a solid policy contribution. ✅

uh, was that an AI review? Please review that review for accuracy. I'm seeing several issues with it.

(@vidakovic the irony here is killing me. 🫣)

@meonkeys Haha no Meonkeys, I just care about wording. If there's something inaccurate, feel free to point it out — happy to discuss

[meonkeys]

@TianHengZhuang please take the time to carefully review the commits, diff, and commit log messages.