docs: introduce AI Policy

[david-allison]

Preview:

• https://github.com/david-allison/Anki-Android/blob/ai-policy/AI_POLICY.md
• https://github.com/david-allison/Anki-Android/blob/ai-policy/CONTRIBUTING.md#ai-policy

---

Low quality contributions from new contributors using AI tools are increasingly becoming a problem.

• Reviewers are putting in more effort into PRs than submitters
• Submitters are unable to explain their changes
• Submitters are falsifying testing data (via LLM hallucinations)
• If mentor comments are fed into an AI, the outcome demotivates mentors and is an inefficient use of their time, as their comments provide no lasting educational value.

If the burden from these contributions increases, it will lead to maintainer burnout, or removing mentorship opportunities for new contributors.

Fixes

• Fixes Define guidelines & processes for LLM/AI-based contributions #19741

Approach

Introduce an AI policy (as a living document, subject to change)

This policy aims to give maintainers a low-effort framework to handle suspected AI-based contributions, allowing mentorship to be redirected towards new human contributors, or established contributors who are trusted to use AI responsibly to augment their work.

The restriction: 3 pull requests was selected because:

• The first issue: 'Fix Android Studio Warnings' should not count
• Two additional merged pull requests display commitment to the repository and ensure that the developer is able to write code without AI tools. It is assumed that they will be more familiar with project norms and will be able to effectively correct any AI-produced output

This policy is light-touch for established contributors: we do not yet have a problem with AI tool usage here and do not want unnecessary processes.

I expect that I will enable Gemini & Android Studio integration in 2026, and do not want to throw the baby out with the bathwater.

Documenting AI usage will be useful for future enforcement if necessary, as well as building trust in contributors, and informing reviewers of 'risky' areas of the code.

"Trivial AI usage" is intentionally left vague, but is expected to include:

• rewording sentences & spelling/grammar improvements
• code reorganization
• minor refactorings
• variable names
• KDoc creation
• producing trivial utility functions

Use of AI here is very likely to be correct. Disclosure of tool use is left to the submitter's discretion to reduce unnecessary process.

Most GitHub comments should not be using AI. This is defined as "should not" as there are reasonable exceptions, such as mass-translating Crowdin strings when verifying translations

How Has This Been Tested?

N/A

Learning (optional, can help others)

• https://discussion.fedoraproject.org/t/council-policy-proposal-policy-on-ai-assisted-contributions/165092?page=4
  • Assisted-by suggestion
• Discussions on Define guidelines & processes for LLM/AI-based contributions #19741
• https://discourse.llvm.org/t/rfc-llvm-ai-tool-policy-human-in-the-loop/89159

ChatGPT said the commit message was too long and too critical 😅

Checklist

• You have a descriptive commit message with a short title (first line, max 50 chars).
• You have commented your code, particularly in hard-to-understand areas
• You have performed a self-review of your own code
• UI changes: include screenshots of all affected screens (in particular showing any new or changed strings)
• UI Changes: You have tested your change using the Google Accessibility Scanner

[ShaanNarendran]

Read through this a few times, and I think it's really solid. Should give newcomers a good idea since the guidelines for ai usage were pretty vague before this.

[mikehardy]

I like it - pretty well thought out at this point, integrated nicely in contrib doc