20251211-forgejo-aiagreement into main
Based on the feedback in #135, I've gone ahead and tried incorporating the Forgejo AIAgreement and expanded it a bit about the background/motivation and necessary license bits.
@ -18,0 +29,4 @@
3. The accountability of using AI in a contribution lies with the person that makes that contribution.
4. All communication, that includes: commit messages, pull request messages, documentation, code comments and issues (and comments on issues/pull requests), that is intended to be read by people to understand your thoughts and work must not have been generated with AI. We exclude machine translation and tooling that helps with grammar and spelling check.
5. Using general AI for review is forbidden. If the change contains changes to the UX it has to be approved by a human reviewer.
6. It is not allowed to use AI in an autonomous-looking way to contribute in Forgejo. This also applies when someone engages in 'vibe coding' or uses so-called 'agent mode'.
Change to CoMaps, but also what does "autonomous looking way" mean? It's unclear what is or isn't allowed overall; we start by saying AI use in code is the committer's responsibility but then we say basically vibecoding is forbidden. Does this mean the only AI usage allowed is narrow AI suggestions or fixes and not "when AI creates a code change (feature, bug fix, tests, refactor) with a human that describes what needs to be implemented."?
Will fix the project, good catch.
I interpret 6 to be: You can't just let your "agent" submit PRs on your behalf, you need to have actively engage with the output of the LLM/bot. If you have an "AI" that does all the writing of code for you, you need to have read, understood and edited it to actually work as expected.
Also see forgejo/discussions#366 (comment) for a detailed explanation of how the rule ended in the Forgejo agreement :)
LGTM. Thank you @jeanbaptisteC and @gedankenstuecke for pulling this.
Why not change destination branch to merge directly in the main branch?
I wanted to suggest it as an improvement to your open WIP work, so that its easier to merge the versions. But if you're happy with it as is, happy to change the destination!
LGTM
@ -0,0 +30,4 @@
2. If at any point you used AI's work in your contribution you should make an effort to verify that you can submit this under the license of the repository.
3. The accountability of using AI in a contribution lies with the person that makes that contribution.
4. All communication, that includes: commit messages, pull request messages, documentation, code comments and issues (and comments on issues/pull requests), that is intended to be read by people to understand your thoughts and work must not have been generated with AI. We exclude machine translation and tooling that helps with grammar and spelling check.
5. Using general AI for review is forbidden. If the change contains changes to the UX it has to be approved by a human reviewer.
I would say every change (aka pull request) needs to be approved by human reviewer. Not just UX related ones.
The reasoning for the UX specific mention in forgejo (from here: forgejo/discussions#366 (comment)) was this:
Reviewing code is one part of the review for a PR. Reviewing the changes by pulling the changes locally and launching Forgejo and having a reviewer experience the change is the second part. AI cannot replace this and changes that impact UX should therefore not be reviewed by AI as they are not the consumers of that change.
I left one hole open where AI could be used for review: narrow AI for specific predefined tasks that don't affect UX, something that people would have previously called machine learning (and still should be calling it). One silly example (that could have been implemented without machine learning) is detecting when a code change is made in the wrong area, such as adding new translations to the legacy locale directory.
But I agree that we can for our use case remove that "loophole"
I've made one more change not suggested so far, but that I think fits our spirit:
We adapted forgejo's guidance as it's CC BY licensed, so it only seems fair that we release our adapted version under the same terms, even if it's not required due to the lack of virality.
What is the case for App Store review replies for example?
To me that falls under All communication, that includes: commit messages, pull request messages, documentation, code comments and issues (and comments on issues/pull requests), that is intended to be read by people to understand your thoughts and work must not have been generated with AI. We exclude machine translation and tooling that helps with grammar and spelling check.
After the last discussions in Zulip, my stand is to consider this as not set hard on stone for all things but a good first step in the right direction. So this can be merge in my opinion and it can be later revised and improved as needed. Thank you @gedankenstuecke and @jeanbaptisteC for your efforts in adding this.
Last question, how to manage code generated by AI cherry pick from OM?
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?