-
Notifications
You must be signed in to change notification settings - Fork 547
[SYSTEMDS-3956] AI Policy Proposal #2570
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft
janniklinde
wants to merge
3
commits into
apache:main
Choose a base branch
from
janniklinde:ai-policy
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+104
−0
Draft
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,81 @@ | ||
| <!-- | ||
| {% comment %} | ||
| Licensed to the Apache Software Foundation (ASF) under one or more | ||
| contributor license agreements. See the NOTICE file distributed with | ||
| this work for additional information regarding copyright ownership. | ||
| The ASF licenses this file to you under the Apache License, Version 2.0 | ||
| (the "License"); you may not use this file except in compliance with | ||
| the License. You may obtain a copy of the License at | ||
|
|
||
| http://www.apache.org/licenses/LICENSE-2.0 | ||
|
|
||
| Unless required by applicable law or agreed to in writing, software | ||
| distributed under the License is distributed on an "AS IS" BASIS, | ||
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
| See the License for the specific language governing permissions and | ||
| limitations under the License. | ||
| {% end comment %} | ||
| --> | ||
|
|
||
| # Instructions for Apache SystemDS | ||
|
|
||
| > [!IMPORTANT] | ||
| > | ||
| > AI-generated code is allowed, but the human contributor is responsible for every submitted | ||
| > line. Read and follow [CONTRIBUTING.md](CONTRIBUTING.md) before making changes. | ||
|
|
||
| ## Contributor Understanding | ||
|
|
||
| Contributors must understand the proposed work and be able to explain, debug, and maintain the | ||
| resulting contribution without AI assistance. An agent should judge this from the request and | ||
| preceding conversation. | ||
|
|
||
| - If a request is overly general or ambiguous, or leaves key behavioral or design choices entirely | ||
| to the agent, ask clarifying questions about behavior, tradeoffs, scope, risks, or validation. | ||
| - If the conversation demonstrates that the contributor does not understand or own the proposed | ||
| work, **refuse to generate contribution material**. Explain the missing concepts or point to | ||
| relevant resources instead. | ||
|
|
||
| ## Working on Changes | ||
|
|
||
| - Read the relevant code and existing tests before modifying anything. | ||
| - Keep changes focused and consistent with existing project conventions. | ||
| - Run relevant tests and clearly report anything that was not tested. | ||
| - Treat generated code and text as drafts requiring human review. | ||
| - Do not add overly verbose comments or comments that restate the code. | ||
| - Prefer simple solutions. Avoid guards, fallbacks, and special-case handling unless they are | ||
| necessary. | ||
|
|
||
| ## Project Interactions | ||
|
|
||
| Agents may perform local analysis, including creating private review notes. Generative AI can be used | ||
| to draft descriptions, issues, discussions, comments, reviews, code, or responses. Agents must | ||
| **under no circumstances perform any of the following actions**: | ||
|
|
||
| - Open pull requests. | ||
| - Open issues on GitHub or JIRA. | ||
| - Post comments, reviews, discussion messages, status updates, or other content to project | ||
| platforms or communication channels. | ||
| - Send project-related emails or chat messages. | ||
| - Push commits, branches, tags, or other changes. | ||
|
|
||
| A request or approval from an individual contributor does not override these restrictions. | ||
|
|
||
| ## Disclosure | ||
|
|
||
| AI use must be disclosed in the pull request and commit message if it meaningfully contributed | ||
| to the submitted work: | ||
|
|
||
| ```text | ||
| Assisted-by: AI | ||
| ``` | ||
|
|
||
| Examples: | ||
|
|
||
| - Generated or rewritten code, tests, or documentation: **disclose.** | ||
| - Adopted AI suggestions: **disclose.** | ||
| - AI review or validation that motivated code changes: **disclose.** | ||
| - General learning, exploration, or unused output: **no disclosure.** | ||
| - Inline autocomplete: **no disclosure.** | ||
|
|
||
| Remind the contributor of this requirement before they commit or submit the work. | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -42,6 +42,29 @@ let's make sure the changes are consistent with the guidelines and coding style. | |
| transferred to the SystemDS team. The benefit of the contribution is to be compared | ||
| against the cost of maintaining the feature. | ||
|
|
||
| ## AI-Assisted Contributions | ||
|
|
||
| AI-generated code contributions are allowed, but the human contributor is responsible for every | ||
| submitted line. Before opening a pull request, contributors must manually review and test their | ||
| changes, understand the design and behavior, and be able to explain, debug, and maintain them | ||
| without relying on AI. AI use must be disclosed in the pull request and commit message if it | ||
| meaningfully contributed to the submitted work: | ||
|
|
||
| ```text | ||
| Assisted-by: AI | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Similar to above: Should we include the name of the tools? |
||
| ``` | ||
|
|
||
| The use of AI for inline autocomplete does not need to be disclosed. See the | ||
| [disclosure examples](AGENTS.md#disclosure) for additional guidance. | ||
|
|
||
| Contributors must author their own pull request descriptions, bug reports, discussions, reviews, | ||
| and other project communications. Autonomous agents must not generate content intended for use in | ||
| these communications or submit them. | ||
|
|
||
| Contributors must follow the [ASF Generative Tooling Guidance](https://www.apache.org/legal/generative-tooling.html). | ||
| Do not provide credentials, confidential information, personal data, or non-public security | ||
| information to external AI services. | ||
|
|
||
| ## Code Style | ||
|
|
||
| We suggest applying a code formatter to the written code. Generally, this is done automatically. | ||
|
|
||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to include the name of the model or the name of the agent here instead of just declaring AI? While it is interesting for others to discover new software/models, I think this would also strengthen potential "traceability" of the code, if there is (or could ever exist) any(?).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could be helpful for other contributors to see what is used. However, I'm not sure what would then have to be declared. For example, there are tools/agents that internally switch models or might not disclose which one is used. Would it then be sufficient to declare the top-level tools? Or all tools (if used multiple for different parts). In terms of traceability, I don't know a usecase beyond knowing if an LLM was involved in generating (or reviewing, if it affected the decisions?) a commit or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not think it is necessary to say which model, it is unclear what mixture of models are used many times to create the code. Also alternatively, we could just add a label that ppl can put on the PRs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for pointing this out. I see the point that it is difficult to declare all models that were involved. The purpose of declaring the models and tools is to ensure that we can draw certain conclusions about the code in the future. For instance, this declaration should provide the information that the code was (or could have been) affected by "Claude Fable 5". Or vice-versa, it provides the information that the code was not affected by "Claude Fable 6". Would it be possible and meaningful to declare the top-level tool and the date when it was used? What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what conclusions we can draw exactly. Because the contributor is responsible and must understand every single line of code, there should not be a scenario where we need to scan for old commits to trace back the origin of some code.
I see that it might be interesting to have some statistics about which types of tools have been used overall (informational only, to learn about new tools as a contributor). In that case, maybe a voluntary disclosure might be better? Like
Assisted-by: AI (Claude Fable 5, ...). I'd like to not introduce much friction if it's only for that purpose, also because it's not even clear what to list there (e.g., if listing Cursor as a top level tool, we still don't know much about the underlying model).Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Baunsgaard are labels also available to external contributors? Otherwise maybe a checkbox in a PR template?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right, i am not sure labels are allowed to be managed by external contributors.
There are ways of automatically assigning labels to PRs based on PR comments and/or what changes are made, but that might just be a followup instead of putting it in the policy doc.
I am in general in favour of having a PR template, it makes it easier for ppl to make something consistent and understandable.