Copilot commented on code in PR #1740: URL: https://github.com/apache/cloudberry/pull/1740#discussion_r3226059351
########## AI_POLICY.md: ########## @@ -0,0 +1,70 @@ +# AI Policy + +We welcome AI tools in Apache Cloudberry development — code assistants, LLMs, AI code review, and beyond. AI is a normal developer tool, like an IDE or a debugger. This document sets simple ground rules so everyone can use AI responsibly. + +## Guidelines + +### 1. You own the code + +AI-generated code carries the same responsibility as code you type yourself. Review it before submitting. If a bug ships, "the AI wrote it" is not a defense. + +**Example:** As an experiment, you used LLM to generate a new type of executor node. The results were impressive, and you wanted to share them with the community. Before opening PR, read every line, verify the logic, and make sure it fits with existing code patterns. Someone might use your code in production, not just for experiments. + +### 2. Same quality bar + +AI-assisted contributions must pass the same review, testing, and CI standards as any other code. No shortcuts. AI-generated code must come with corresponding tests, or be covered by existing ones. If the AI wrote the code, you should at least write or carefully verify the tests. + +**Example:** You use an LLM to implement a new aggregate function. The PR must include regression tests in `src/test` that exercise both normal and edge cases. + +### 3. Watch the license + +Don't let AI introduce code incompatible with the Apache License 2.0. You are responsible for ensuring all submitted code — AI-generated or not — has proper licensing. + +See [ASF Generative Tooling Guidance](https://www.apache.org/legal/generative-tooling.html) for details. + +**Example:** If an AI tool reproduces a snippet from a GPL-licensed project, you must not include it. When in doubt, rewrite from scratch. + +### 4. Flag it + +When your PR includes significant AI-generated code, check the AI disclosure box in the PR template. You don't have to disclose minor AI assistance (autocomplete, reformatting), but be transparent about substantial generation. + +**Example:** Using LLM to autocomplete a single function signature - no need for a flag. Using LLMs to generate an entire new GUC parameter with validation logic - flag it. The flag doesn't mean that the PR doesn't need to be reviewed or merged, but it will give reviewers more information about the code generation method and allow them to focus more on checking the architecture and logic, rather than specific operators. + +### 5. No meaningless code refactoring + +Our core is PostgreSQL, and refactoring work has already been done here. Rewriting code significantly complicates rebase. Also, refactoring changes the code in a way that forces people to relearn the code they already know. Keep changes as simple as possible. + +**Example:** The point of LLM is to spend your tokens. One day, you will be asked: "This code is not very good. Do you want to improve it?" Of course! It could happens several times. Tokens are spent, but what is the point of such refactoring? (Rhetorical question) Review Comment: The example text here contains a grammatical error: "It could happens several times." Please correct this sentence to proper English to keep the policy document professional and clear. ########## AI_POLICY.md: ########## @@ -0,0 +1,70 @@ +# AI Policy + +We welcome AI tools in Apache Cloudberry development — code assistants, LLMs, AI code review, and beyond. AI is a normal developer tool, like an IDE or a debugger. This document sets simple ground rules so everyone can use AI responsibly. Review Comment: AI_POLICY.md is missing the standard ASF license header comment block that other top-level Markdown docs include. This is likely to trigger the Apache RAT audit and is inconsistent with files like README.md/CONTRIBUTING.md/SECURITY.md. Add the ASF header at the top (as an HTML comment) for license compliance. ########## AI_POLICY.md: ########## @@ -0,0 +1,70 @@ +# AI Policy + +We welcome AI tools in Apache Cloudberry development — code assistants, LLMs, AI code review, and beyond. AI is a normal developer tool, like an IDE or a debugger. This document sets simple ground rules so everyone can use AI responsibly. + +## Guidelines + +### 1. You own the code + +AI-generated code carries the same responsibility as code you type yourself. Review it before submitting. If a bug ships, "the AI wrote it" is not a defense. + +**Example:** As an experiment, you used LLM to generate a new type of executor node. The results were impressive, and you wanted to share them with the community. Before opening PR, read every line, verify the logic, and make sure it fits with existing code patterns. Someone might use your code in production, not just for experiments. + +### 2. Same quality bar + +AI-assisted contributions must pass the same review, testing, and CI standards as any other code. No shortcuts. AI-generated code must come with corresponding tests, or be covered by existing ones. If the AI wrote the code, you should at least write or carefully verify the tests. + +**Example:** You use an LLM to implement a new aggregate function. The PR must include regression tests in `src/test` that exercise both normal and edge cases. + +### 3. Watch the license + +Don't let AI introduce code incompatible with the Apache License 2.0. You are responsible for ensuring all submitted code — AI-generated or not — has proper licensing. + +See [ASF Generative Tooling Guidance](https://www.apache.org/legal/generative-tooling.html) for details. + +**Example:** If an AI tool reproduces a snippet from a GPL-licensed project, you must not include it. When in doubt, rewrite from scratch. + +### 4. Flag it + +When your PR includes significant AI-generated code, check the AI disclosure box in the PR template. You don't have to disclose minor AI assistance (autocomplete, reformatting), but be transparent about substantial generation. + +**Example:** Using LLM to autocomplete a single function signature - no need for a flag. Using LLMs to generate an entire new GUC parameter with validation logic - flag it. The flag doesn't mean that the PR doesn't need to be reviewed or merged, but it will give reviewers more information about the code generation method and allow them to focus more on checking the architecture and logic, rather than specific operators. + +### 5. No meaningless code refactoring + +Our core is PostgreSQL, and refactoring work has already been done here. Rewriting code significantly complicates rebase. Also, refactoring changes the code in a way that forces people to relearn the code they already know. Keep changes as simple as possible. + +**Example:** The point of LLM is to spend your tokens. One day, you will be asked: "This code is not very good. Do you want to improve it?" Of course! It could happens several times. Tokens are spent, but what is the point of such refactoring? (Rhetorical question) + +### 6. LLM code review + +So far, it is not possible to use paid LLM models for code review in open source ASF projects. However, one could use personal licenses for LLMs to do the same. Review Comment: This section makes a factual claim about what is/isn't allowed for paid LLM code review in ASF open source projects, but it isn't linked to an authoritative ASF policy. To avoid publishing potentially incorrect guidance, please either cite the exact ASF guidance that establishes this restriction or rephrase it as a recommendation without asserting a blanket prohibition. ########## AI_POLICY.md: ########## @@ -0,0 +1,70 @@ +# AI Policy + +We welcome AI tools in Apache Cloudberry development — code assistants, LLMs, AI code review, and beyond. AI is a normal developer tool, like an IDE or a debugger. This document sets simple ground rules so everyone can use AI responsibly. + +## Guidelines + +### 1. You own the code + +AI-generated code carries the same responsibility as code you type yourself. Review it before submitting. If a bug ships, "the AI wrote it" is not a defense. + +**Example:** As an experiment, you used LLM to generate a new type of executor node. The results were impressive, and you wanted to share them with the community. Before opening PR, read every line, verify the logic, and make sure it fits with existing code patterns. Someone might use your code in production, not just for experiments. + +### 2. Same quality bar + +AI-assisted contributions must pass the same review, testing, and CI standards as any other code. No shortcuts. AI-generated code must come with corresponding tests, or be covered by existing ones. If the AI wrote the code, you should at least write or carefully verify the tests. + +**Example:** You use an LLM to implement a new aggregate function. The PR must include regression tests in `src/test` that exercise both normal and edge cases. + +### 3. Watch the license + +Don't let AI introduce code incompatible with the Apache License 2.0. You are responsible for ensuring all submitted code — AI-generated or not — has proper licensing. + +See [ASF Generative Tooling Guidance](https://www.apache.org/legal/generative-tooling.html) for details. + +**Example:** If an AI tool reproduces a snippet from a GPL-licensed project, you must not include it. When in doubt, rewrite from scratch. + +### 4. Flag it + +When your PR includes significant AI-generated code, check the AI disclosure box in the PR template. You don't have to disclose minor AI assistance (autocomplete, reformatting), but be transparent about substantial generation. + +**Example:** Using LLM to autocomplete a single function signature - no need for a flag. Using LLMs to generate an entire new GUC parameter with validation logic - flag it. The flag doesn't mean that the PR doesn't need to be reviewed or merged, but it will give reviewers more information about the code generation method and allow them to focus more on checking the architecture and logic, rather than specific operators. + +### 5. No meaningless code refactoring + +Our core is PostgreSQL, and refactoring work has already been done here. Rewriting code significantly complicates rebase. Also, refactoring changes the code in a way that forces people to relearn the code they already know. Keep changes as simple as possible. + +**Example:** The point of LLM is to spend your tokens. One day, you will be asked: "This code is not very good. Do you want to improve it?" Of course! It could happens several times. Tokens are spent, but what is the point of such refactoring? (Rhetorical question) + +### 6. LLM code review + +So far, it is not possible to use paid LLM models for code review in open source ASF projects. However, one could use personal licenses for LLMs to do the same. + +**Example:** We primarily use GitHub Copilot for automated AI code review on pull requests. Here are some important points: + +- Copilot suggestions are **non-binding hints**, not requirements. +- If a suggestion is irrelevant or wrong, skip it — you know your code best. +- If a suggestion catches a real issue, fix it like you would for any review comment. +- Copilot does not replace human reviewers. All PRs still need approval from a committer. + +### 7. Talk to maintainers yourself + +Do not use AI to auto-generate responses to review feedback. Maintainers invest time reviewing your code; respond thoughtfully and personally. + +**Example:** A reviewer asks "why did you choose this approach over X?" — write your own answer explaining the tradeoff, don't paste an LLM-generated reply. + +## Good uses of AI + +- Bug fixing and root cause analysis +- Code review +- Writing and improving tests +- Documentation and code comments +- Build system and CI improvements +- Security research and vulnerability scanning +- Learning the codebase faster + +## Resources + +- [ASF Generative Tooling Guidance](https://www.apache.org/legal/generative-tooling.html) - Official Apache guidance on AI tool usage +- [GitHub Copilot](https://github.com/features/copilot) - AI pair programmer and code reviewer we use +- [LLM Leaderboard](https://llm-stats.com/) - LLM Stats Score, it's better to use high-ranked models Review Comment: Linking to an external "LLM Leaderboard" and recommending using "high-ranked models" reads like an endorsement and will become stale quickly. Consider removing this resource or replacing it with stable ASF/Apache guidance (or neutral criteria like license compatibility, data handling, and model provider terms). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
