AI Policy¶

This policy is based on the Open edX AI Contribution Policy, with some modifications to suit our use cases better.

This policy applies to OpenCraft members in the course of their work, when working on OpenCraft internal work or contributing to third parties that don't already have an AI policy.

Important notes¶

Please note that members remain obligated to comply with all terms of any Contributor License Agreement (CLA), including without limitation having a legal right to assign ownership and copyright of works to OpenCraft.
For anything related to Open edX, we must align our work with the Open edX AI Contribution Policy. That includes respecting that policy's list of allowed tools, and this applies even for internal work which isn't planned to be contributed upstream. We need to preserve the possibility to contribute any Open edX related work there, and not have to keep track of different histories/origins.
Never use cloud-based LLMs on a repository or documents that contain secrets, like infrastructure repos. This can result in secrets being used for training and potentially recoverable by other LLM users.

Allowed tools¶

OpenCraft does not directly place any restrictions on what tools, LLM models, or services are used.

However, please note that the Open edX AI Contribution Policy does have restrictions. We must also respect these restrictions for any internal work related to Open edX, whether it has an upstreaming plan yet or not.

We can't always envision all the cases, and we need to make sure we won't be blocked from contributing something later, or have to track and check whenever we need to contribute something. In practice, this affects most code and documentation we write at OpenCraft, due to our goal of eventually upstreaming as much as possible.

For code/document writing¶

OpenCraft welcomes the use of AI tools as part of your contribution workflow. Please make informed decisions on the tools you use, also considering ethical, quality, and privacy aspects. Open source tools and AI models are encouraged.

AI can be genuinely useful: for learning a new part of the codebase, drafting descriptions, thinking through a problem, or keeping track of a complex review. The goal of this policy is not to restrict AI use, but to ensure that contributions reflect real understanding and that AI use is transparent.

Two principles underpin everything here:

Understanding: You are responsible for what you submit. Using AI to generate code or text you don't understand is not a shortcut; it shifts work onto reviewers and maintainers without adding value. Using AI to build understanding is encouraged.
Transparency: "Is this AI?" is not a fruitful question standing alone. Disclose AI use clearly, so reviewers can calibrate their expectations and everyone stays on the same page.

A Note on Quality

The goal of this policy is not to track AI use for its own sake. It is to maintain the quality and reviewability of contributions to a large, complex platform that many institutions and learners depend on. Unnecessary code churn, bypassed tests, and unreviewed AI output all have real downstream costs.

You can use AI extensively and produce excellent contributions. You can also produce low-quality contributions without using AI at all. What matters is understanding, care, and transparency, regardless of the tools involved.

Pull requests¶

Contributor requirements¶

Disclose AI use explicitly. If AI tools contributed meaningfully to your PR (code, tests, or description), say so in the PR description. Use GitHub's co-author feature where applicable (e.g., Co-authored-by: Claude <claude@anthropic.com>). Please consider sharing your AI conversation log directly in the PR description, or link to the log in a GitHub Gist. There is no penalty for disclosure; there is a problem with concealment.
Understand the code you are submitting. Before opening a non-draft PR, you must be able to explain what the proposed changes do and why they are correct. If a reviewer asks you about your implementation and your honest answer is "I'm not sure, the AI did it," the PR is not ready, and your PR will likely be closed.
Review all AI-generated output before submitting. You are responsible for all code or other material you submit, including its quality and appropriateness for contribution.
Verify the accuracy of AI-generated material. This includes everything you contribute: PR descriptions, inline comments, and responses to reviewer feedback. If an AI tells you that review feedback has been addressed, verify that it actually has been. Do not relay AI output as your own assessment.
Feel free to use AI to improve documentation. When you submit a PR, consider using AI to help determine which changes would be appropriate to make to relevant documentation. Make sure to apply the same quality review and human curation to documentation that you would to code PRs.

Issue reports and triage¶

The same principles apply to issue reports:

Disclose AI use. If AI helped you write or structure the issue, say so.
Understand what you are filing. AI-generated issue reports often lack the specific reproduction steps, environmental context, and genuine debugging effort that make issues actionable. Do not file an issue you could not discuss or expand on if asked.

When reviewing issues from external contributors that appear fully AI-generated without legitimate investigation, consider asking the author for confirmation, to check for AI hallucinations. Consider closing unproductive issues, and consider blocking external contributors who repeatedly open unproductive issues.

Acceptable uses¶

AI tools are well-suited to:

Familiarizing yourself with an unfamiliar part of the codebase
Drafting PR descriptions or issue reports (with human review and editing)
Assisting with writing in a non-native language
Talking through a design decision or debugging approach
Assisting reviewers in understanding a large or complex diff

These are uses that support human understanding and judgment, not a substitute for it.

⚠️ Common AI Tool Antipatterns¶

Be on the lookout for common AI tool patterns that lower the quality of your contribution. AI tools commonly:

Rewrite entire code blocks when a small, focused edit was needed, making diffs harder to review and introducing unintended changes.
Fix failing tests by altering or bypassing them rather than addressing the underlying problem.
Generate comments that describe what the code does rather than why, adding noise without value.

It is your responsibility to catch and correct these issues before requesting review.

❌ Bad flow: no human understanding anywhere in the loop¶

Contributor prompts an LLM with a link to a GitHub issue: "Fix this and open a PR."
Reviewer prompts an LLM with a link to the PR: "Review this."
LLM responds "LGTM." PR is merged.

Result: code enters the codebase that no human has read or understood.

❌ Bad flow: review loop with no real engagement¶

Contributor prompts an LLM with a link to a GitHub issue: "Fix this and open a PR."
Reviewer reviews and leaves comments.
Contributor prompts an LLM with a link to the review: "Address this feedback."
Repeat indefinitely.

Result: the reviewer is effectively collaborating with a very high-latency LLM. No matter how many rounds this takes, it is not a productive review process.

✅ Good flow: AI assists, humans understand¶

Contributor prompts an LLM with context about the issue.
Contributor reviews the output, makes sure they understand the changes, adjusts as needed, and submits the PR with appropriate disclosure.
Reviewer uses an LLM to help understand the diff or organize their thoughts.
Reviewer verifies they understand the changes and any suggestions before writing their review.
Reviewer comments. Contributor engages with the feedback directly, using their own understanding of the code.

Result: AI accelerates the work. Humans remain responsible for it.

For reviewing¶

Reviewer time is limited. If you are a reviewer, you are not obligated to continue reviewing a PR that shows signs the contributor has not followed this policy.

Red flags include:

The PR description does not match the changes (the contributor did not review both carefully enough to notice).
The PR contains irrelevant AI-generated files (e.g., agent planning notes, scaffolding files).
Review responses do not engage with feedback; they restate or reformat rather than address it.
The contributor cannot explain their own changes when asked directly.

If this is a contribution from an external contributor, consider voicing your concerns and closing the PR.

However, if you are a reviewing a PR from a fellow OpenCraft member and have concerns, don't simply close the PR. Please discuss this with them first, involving other team members if necessary.

Beware the sunk cost fallacy. If at any point you feel you are effectively acting as a high-latency prompt engineer (feeding feedback into a loop that returns minimally filtered AI output), it is appropriate to raise your concerns (and for PRs from external contributors, close the PR). This applies even after multiple review rounds.

You may also use AI tools to assist your review. If you do, disclose it, for example:

Co-authored with Claude

or

Co-reviewed with Claude

Consider also describing how you used the AI tools. For example:

I used it to talk through the changes, track my notes, and help draft this summary. All conclusions are my own.