fnetX commented 2025年06月26日 12:20:08 +02:00

Hey everyone,

I'd like to continue the discussion from forgejo/forgejo#8285 because I think it is an important one to have. There have been bilateral conversations about this matter between me and several other team members, but I suppose that it's time to discuss this in the open.

Some questions to get the discussion started:

• Do we allow the use of generative AI for contributions to Forgejo?
• Which demand do we have regarding transparency on the integration of AI?
• What do we expect from contributors who use AI?
• How do we deal with contributions that do not meet our expectations regarding the usage of AI?

Hey everyone, I'd like to continue the discussion from https://codeberg.org/forgejo/forgejo/pulls/8285 because I think it is an important one to have. There have been bilateral conversations about this matter between me and several other team members, but I suppose that it's time to discuss this in the open. Some questions to get the discussion started: * Do we allow the use of generative AI for contributions to Forgejo? * Which demand do we have regarding transparency on the integration of AI? * What do we expect from contributors who use AI? * How do we deal with contributions that do not meet our expectations regarding the usage of AI?

fnetX commented 2025年06月26日 12:35:28 +02:00

My personal view:

I'm not a big fan of AI tools, as many people know. In many cases, it procudes verbose garbage. Sometimes it works, but often, it's not the code quality I'd like to see integrated in Forgejo. It might be hard to read and maintain, without using more AI tools on top of it.

My primary concern with regards to AI usage is the additional burden it places on me and other Forgejo maintainers to deal with the code. AI code and descriptions are usually much more verbose than human-written content. It takes more time to read and understand, it makes more effort to maintain in the long term. I don't mind if some skilled developer uses some AI to assist with coding. But I am opposed to having people use AI to generate code they apparently don't even understand themself, because this makes it really hard to fix and maintain the code after it was merged.

In the trigger example in forgejo/forgejo#8285, I didn't read much past the description. It's a wall of text, fancied up with useless icons to cover the fact that it is simply too much text. The structure is not typical to PRs in Forgejo, it's the typical repetitive tone of AI-written stuff. The PR does not reference an existing problem. It just fires off a bunch of allegedly improvements, mentioning things like connection pooling and reuse multiple times. It could have been shortened to one (!) list of improvements that is easy to scan, followed by the benchmarks if necessary.

And the structure by AI doesn't even make sense when reading carefully. For example, I don't think that "Consistency: Centralized configuration and behavior across all services" can be considered a "Performance benefit", but it's listed there. That's the pain problem with AI. It all sounds good on first scan, because it's verbose and well-written text. But the content doesn't make much sense if you read slowly and think about it. And this burden to read and think about it is shifted from the contributors to the Forgejo maintainers. I disagree to this!

I must admit, that I have used AI for contributions to Forgejo in the past. The only example I still recall is some Typescript code, that I didn't manage to get right, even after using normal search engines. I was tired, and frustrated, and generated something. Then threw away most of it, because it wasn't what I actually needed. From forgejo/forgejo@8723da989d, lines 15 - 25 originate from AI, which suggested using interfaces (which I didn't know about before). In the final commit, no single line of code that was generated by AI has been committed as-is. I had to rewrite everything by hand to match my evolving ideas (different naming and different structure). I would argue that this has not created additional burden on the reviewers of the PR and is perfectly in scope of contributions to Forgejo.

I am open for highlighting things that were generated by or with the help of AI tooling, to allow reviewers to either refuse to review this content, or give it a much more careful look.

My personal view: I'm not a big fan of AI tools, as many people know. In many cases, it procudes verbose garbage. Sometimes it works, but often, it's not the code quality I'd like to see integrated in Forgejo. It might be hard to read and maintain, without using more AI tools on top of it. My primary concern with regards to AI usage is the additional **burden it places on me and other Forgejo maintainers** to deal with the code. AI code and descriptions are usually much more verbose than human-written content. It takes more time to read and understand, it makes more effort to maintain in the long term. I don't mind if some skilled developer uses some AI to assist with coding. But I am opposed to having people use AI to generate code they [apparently don't even understand themself](https://codeberg.org/forgejo/forgejo/pulls/7212#issuecomment-3091512), because this makes it really hard to fix and maintain the code after it was merged. In the trigger example in https://codeberg.org/forgejo/forgejo/pulls/8285, I didn't read much past the description. It's a wall of text, fancied up with useless icons to cover the fact that it is simply too much text. The structure is not typical to PRs in Forgejo, it's the typical repetitive tone of AI-written stuff. The PR does not reference an existing problem. It just fires off a bunch of allegedly improvements, mentioning things like connection pooling and reuse **multiple times.** It could have been shortened to one (!) list of improvements that is easy to scan, followed by the benchmarks if necessary. And the structure by AI **doesn't even make sense when reading carefully.** For example, I don't think that "Consistency: Centralized configuration and behavior across all services" can be considered a "Performance benefit", but it's listed there. That's the pain problem with AI. It all sounds good on first scan, because it's verbose and well-written text. But the content doesn't make much sense if you read slowly and think about it. And this **burden to read and think about it is shifted from the contributors to the Forgejo maintainers**. I disagree to this! I must admit, that I have used AI for contributions to Forgejo in the past. The only example I still recall is some Typescript code, that I didn't manage to get right, even after using normal search engines. I was tired, and frustrated, and generated something. Then threw away most of it, because it wasn't what I actually needed. From https://codeberg.org/forgejo/forgejo/commit/8723da989d416b954c63b889a78a6c5bc1870626, lines 15 - 25 originate from AI, which suggested using interfaces (which I didn't know about before). In the final commit, no single line of code that was generated by AI has been committed as-is. I had to rewrite everything by hand to match my evolving ideas (different naming and different structure). I would argue that this has not created additional burden on the reviewers of the PR and is perfectly in scope of contributions to Forgejo. I am open for highlighting things that were generated by or with the help of AI tooling, to allow reviewers to either refuse to review this content, or give it a much more careful look.

n0toose commented 2025年06月26日 15:18:23 +02:00

I am for a ban of LLMs in the context of providing technical explanations and justifications in Forgejo spaces. If a contribution should be included in Forgejo, authors should be in a position to give explanations by themselves. I would not be opposed for it if the person at the other end feels the need to use it because of e.g. inadequate English skills.

As far as code-related contributions are concerned, I think we should just skip to the part where we proclaim that "we found out that we don't like this and it's a waste of time" like many other projects. I am not strictly against people employing such tools to ask mere questions ("how to do X and Y in Go?"), nor can we control that (and IMHO shouldn't).

I am for a ban of LLMs in the context of providing technical explanations and justifications in Forgejo spaces. If a contribution should be included in Forgejo, authors should be in a position to give explanations by themselves. I would not be opposed for it if the person at the other end feels the need to use it because of e.g. inadequate English skills. As far as code-related contributions are concerned, I think we should just skip to the part where we proclaim that "we found out that we don't like this and it's a waste of time" like many other projects. I am not strictly against people employing such tools to ask mere questions ("how to do X and Y in Go?"), nor can we control that (and IMHO shouldn't).

pat-s commented 2025年06月26日 16:16:06 +02:00

I am for a ban of LLMs in the context of providing technical explanations and justifications in Forgejo spaces.

This is a very shortsighted view imo. Such summaries are not generally bad, the main issue (and I agree on that and the general criticism also raised by Otto) is that they are often repetitive and verbose. However, they also include useful things one would likely have not reported over even overlooked (depending on the size and complexity of the contribution).

I don't think the goal should necessary be to "mask" such things, neither in code or verbal forms, as this is just whitewashing in the end.
I see and can understand the need for the active curation of such contents by authors (and I apologize and acknowledge I didn't do that in a good way in the linked PR). However, we are all humans and devs, and we usually tend to write "too less" in many ways, being it code comments or descriptions of changes. Because we're lazy.
And I don't think this fact should be embraced either.

Especially when developing solo, one often doesn't add much or any context, making it hard for others to follow. I agree that a super verbose auto-generated summary isn't ideal either, but rather a middle-way is (as usually for any case).

Last, I really hope that this spark does not start an active (shortsighted) movement against the use of AI for either code or summaries.
Both cannot clearly detected anyhow and balking against a new (technical) development such as AI is much like other historic events when people ranted against the use/uprise of git,smartphones,internet,cloud,younameit. I really hope we're not going this way here.
While it may sound hard, in the age of AI one has to overcome the proudness of being a coding genius and being angry about an AI being better at this but rather accept it, "make the best out of it" and look ahead. "Coding for projects" in the future will inevitably be more focused around governance, organization and the "idea" behind a project rather than its actual codebase. This might not sound romantic to some but it is simply the hard truth. OTOH this can also be a chance for people/the com behind it, as it opens up the field to many, which previously were stuck at medium to complex problems which only a few (geniuses) could tackle.

> I am for a ban of LLMs in the context of providing technical explanations and justifications in Forgejo spaces. This is a very shortsighted view imo. Such summaries are not *generally* bad, the main issue (and I agree on that and the general criticism also raised by Otto) is that they are often repetitive and verbose. However, they also include useful things one would likely have not reported over even overlooked (depending on the size and complexity of the contribution). I don't think the goal should necessary be to "mask" such things, neither in code or verbal forms, as this is just whitewashing in the end. I see and can understand the need for the active curation of such contents by authors (and I apologize and acknowledge I didn't do that in a good way in the linked PR). However, we are all humans and devs, and we usually tend to write "too less" in many ways, being it code comments or descriptions of changes. Because we're lazy. And I don't think this fact should be embraced either. Especially when developing solo, one often doesn't add much or any context, making it hard for others to follow. I agree that a super verbose auto-generated summary isn't ideal either, but rather a middle-way is (as usually for any case). Last, I really hope that this spark does not start an active (shortsighted) movement against the use of AI for either code or summaries. Both cannot clearly detected anyhow and balking against a new (technical) development such as AI is much like other historic events when people ranted against the use/uprise of git,smartphones,internet,cloud,younameit. **I really hope we're not going this way here**.\ While it may sound hard, in the age of AI one has to overcome the proudness of being a coding genius and being angry about an AI being better at this but rather accept it, "make the best out of it" and look ahead. "Coding for projects" in the future will inevitably be more focused around governance, organization and the "idea" behind a project rather than its actual codebase. This might not sound romantic to some but it is simply the hard truth. OTOH this can also be a chance for people/the com behind it, as it opens up the field to many, which previously were stuck at medium to complex problems which only a few (geniuses) could tackle.

n0toose commented 2025年06月26日 17:30:33 +02:00

This is a very shortsighted view imo.

However, they also include useful things one would likely have not reported over even overlooked (depending on the size and complexity of the contribution).

As I already said above, I don't disagree with "asking" - you can ask an AI if you missed something and then go over it yourself (that would be making "the best out of it"). I would understand if you were using tools for things that they are good for, but you are relying on them largely or fully for communication to a large degree. From my point of view, you, personally, can either explain what you did in your own words or you can't. As I've said many times, this is not a good way for you to use AI when dealing with the human beings behind your display - it just causes them deep frustration.

The "democratizing code from egotistical, self-centered geniuses" shtick with a "like it or not / get over it" vibe is not convincing - I don't think in "geniuses", as I've never been able to submit a PR without three thousand review rounds required (but that's just me learning :D). When other fellow contributors say "I feel like your methodology is wasting my time, right here, right now", that's... just, not it. Anyway, my view is based on precedent and the present - which you defined in the context of this space, and not "the futureTM️" - and it is "I'm feeling quite annoyed right now, and don't want to deal with any of that again in the near future", so I'll take a walk for now or cook a nice evening omelette. Peace o/

> This is a very shortsighted view imo. > However, they also include useful things one would likely have not reported over even overlooked (depending on the size and complexity of the contribution). As I already said above, I don't disagree with "asking" - you can ask an AI if you missed something and then go over it yourself (*that* would be making "the best out of it"). I would understand if you *were* using tools for things that they are good for, but you are relying on them largely or fully for communication to a large degree. From my point of view, you, ***personally***, can either explain what you did in your own words or you can't. As I've said many times, this ***is not*** a good way for *you* to use AI when dealing with the human beings behind your display - it just causes them deep frustration. The "democratizing code from egotistical, self-centered geniuses" shtick with a "like it or not / get over it" vibe is not convincing - I don't think in "geniuses", as I've never been able to submit a PR without three thousand review rounds required (but that's just me learning :D). When other fellow contributors say "I feel like *your* methodology is wasting *my* time, *right here, right now*", that's... just, not it. Anyway, my view is based on precedent and the present - which you defined in the context of this space, and not "the future:tm:" - and it is "I'm feeling quite annoyed right now, and don't want to deal with any of that again in the near future", so I'll take a walk for now or cook a nice evening omelette. Peace o/

Beowulf commented 2025年06月26日 17:41:43 +02:00

I agree that AI shouldn't be a primary tool, but it can be used as a supporting tool (just like you use linters, code completion, etc). What I find particularly ridiculous is that people give an AI bullet points to write a longer message, and on the other hand a human now has to find the key points or even use an AI to find the bullet points again.

I think, for example, if a issue or PR is primarily AI work, it's fine to close it for that reason. Because this approach can also indicate that the creator is not really motivated to work on it and will not address reviews.

I agree that AI shouldn't be a primary tool, but it can be used as a supporting tool (just like you use linters, code completion, etc). What I find particularly ridiculous is that people give an AI bullet points to write a longer message, and on the other hand a human now has to find the key points or even use an AI to find the bullet points again. I think, for example, if a issue or PR is primarily AI work, it's fine to close it for that reason. Because this approach can also indicate that the creator is not really motivated to work on it and will not address reviews.

Ryuno-Ki commented 2025年06月26日 18:01:46 +02:00

I'm going to share my answers to your questions first before explaining the rationale and experience.

@fnetX wrote in #366 (comment):

Some questions to get the discussion started:

* Do we allow the use of generative AI for contributions to Forgejo?
* Which demand do we have regarding transparency on the integration of AI?
* What do we expect from contributors who use AI?
* How do we deal with contributions that do not meet our expectations regarding the usage of AI?

• I'm against accepting contributions with the use of generative AI.
• If AI was used, it should be highlighted (I've seen that happened in the links you provided)
• I expect them to be transparent of the use of AI.
• We should seek a conversation with them.

Experience

I do not use AI over ethical and ecological concerns. It's a bubble that will burst.

That being said, I reviewed code that was co-written by AI in the Keyoxide project (hosted on Codeberg). In a conversation with the author I learned that the AI was useless for creating meaningful parts of the PR as it was simply too niche to be known to the dataset the AI was trained with. That being said, coming up with the regular expressions that formed a core part of the PR, was assisted by AI. I can understand that. Regular Expressions are challenging to wrap one's head around.
Nevertheless the conversation with me (as reviewer) was tremendeously helpful in learning what was going on.
We identified the need to improve our onboarding guidelines (still hasn't happened because $REASONS).

So ... if the people feel the need to use AI it could be a signal that the documentation isn't good enough or they feel not psychological safe to speak up. We wouldn't be able to work on it with no transparency.

Rationale

Regarding Codeberg in particular: People move their projects here over its position to not welcome AI. As patron over Forgejo I would expect this stance to be applied to Forgejo.

Let's not forget that the use of AI has a tendency to reduce the ability to think critically. On the code side, small oversights can lead to security issues. If nobody thinks through the code (on the writer as well as on the reader side) we miss an opportunity to catch them.

If the text is too verbose or the code does too many things, one way out would be to ask for breaking up a PR.
That's a strategy I see working (with the LernTools project, hosted on Codeberg). The large PR serves as Big Picture while the smaller PRs are easier to review.

I'm going to share my answers to your questions first before explaining the rationale and experience. @fnetX wrote in https://codeberg.org/forgejo/discussions/issues/366#issue-1886996: > Some questions to get the discussion started: > > * Do we allow the use of generative AI for contributions to Forgejo? > > * Which demand do we have regarding transparency on the integration of AI? > > * What do we expect from contributors who use AI? > > * How do we deal with contributions that do not meet our expectations regarding the usage of AI? * I'm against accepting contributions with the use of generative AI. * If AI was used, it should be highlighted (I've seen that happened in the links you provided) * I expect them to be transparent of the use of AI. * We should seek a conversation with them. ## Experience I do not use AI over ethical and ecological concerns. It's a bubble that will burst. That being said, I reviewed code that was co-written by AI in the Keyoxide project (hosted on Codeberg). In a conversation with the author I learned that the AI was useless for creating meaningful parts of the PR as it was simply too niche to be known to the dataset the AI was trained with. That being said, coming up with the regular expressions that formed a core part of the PR, was assisted by AI. I can understand that. Regular Expressions are challenging to wrap one's head around. Nevertheless the conversation with me (as reviewer) was tremendeously helpful in learning what was going on. We identified the need to improve our onboarding guidelines (still hasn't happened because $REASONS). So ... if the people feel the need to use AI it could be a signal that the documentation isn't good enough or they feel not psychological safe to speak up. We wouldn't be able to work on it with no transparency. ## Rationale Regarding Codeberg in particular: People move their projects here over its position to not welcome AI. As patron over Forgejo I would expect this stance to be applied to Forgejo. Let's not forget that the use of AI has a tendency to reduce the ability to think critically. On the code side, small oversights can lead to security issues. If nobody thinks through the code (on the writer as well as on the reader side) we miss an opportunity to catch them. If the text is too verbose or the code does too many things, one way out would be to ask for breaking up a PR. That's a strategy I see working (with the LernTools project, hosted on Codeberg). The large PR serves as Big Picture while the smaller PRs are easier to review.

quokka commented 2025年06月26日 18:46:51 +02:00

@Ryuno-Ki wrote in #366 (comment):

That being said, I reviewed code that was co-written by AI in the Keyoxide project (hosted on Codeberg). In a conversation with the author I learned that the AI was useless for creating meaningful parts of the PR as it was simply too niche to be known to the dataset the AI was trained with. That being said, coming up with the regular expressions that formed a core part of the PR, was assisted by AI. I can understand that. Regular Expressions are challenging to wrap one's head around. Nevertheless the conversation with me (as reviewer) was tremendeously helpful in learning what was going on. We identified the need to improve our onboarding guidelines (still hasn't happened because $REASONS).

Just to clarify, I am this contributor.

---

Here are my opinions on your questions:

Do we allow the use of generative AI for contributions to Forgejo?

In my opinion, yes, as long as it's AI-assisted and not completely AI-generated.

Which demand do we have regarding transparency on the integration of AI?

I'd say probably make it clear that AI was used in commits, issues, PRs, etc., and if possible to point out exactly where AI was used.

What do we expect from contributors who use AI?

We should expect them to be truthful about their usage of AI tools, and for them to be competent enough to comprehend, review, and redact the AI's output and not just blindly trust it.

How do we deal with contributions that do not meet our expectations regarding the usage of AI?

I think people who spam low-quality AI garbage should absolutely not be tolerated here.

---

Maybe I'll write about my experience and rationale too later, but I'm tired rn T-T

@Ryuno-Ki wrote in https://codeberg.org/forgejo/discussions/issues/366#issuecomment-5612786: > > That being said, I reviewed code that was co-written by AI in the Keyoxide project (hosted on Codeberg). In a conversation with the author I learned that the AI was useless for creating meaningful parts of the PR as it was simply too niche to be known to the dataset the AI was trained with. That being said, coming up with the regular expressions that formed a core part of the PR, was assisted by AI. I can understand that. Regular Expressions are challenging to wrap one's head around. Nevertheless the conversation with me (as reviewer) was tremendeously helpful in learning what was going on. We identified the need to improve our onboarding guidelines (still hasn't happened because $REASONS). Just to clarify, I am this contributor. --- Here are my opinions on your questions: > Do we allow the use of generative AI for contributions to Forgejo? In my opinion, yes, as long as it's AI-assisted and not completely AI-generated. > Which demand do we have regarding transparency on the integration of AI? I'd say probably make it clear that AI was used in commits, issues, PRs, etc., and if possible to point out exactly where AI was used. > What do we expect from contributors who use AI? We should expect them to be truthful about their usage of AI tools, and for them to be competent enough to comprehend, review, and redact the AI's output and not just blindly trust it. > How do we deal with contributions that do not meet our expectations regarding the usage of AI? I think people who spam low-quality AI garbage should absolutely not be tolerated here. --- Maybe I'll write about my experience and rationale too later, but I'm tired rn T-T

fnetX commented 2025年06月26日 19:20:35 +02:00

I assume that different projects have different needs, and think it makes sense to focus on Forgejo. It's good to read about the experiences in other projects, but maybe they can be made available somewhere else and only referenced, so interested participants can read them?

I assume that different projects have different needs, and think it makes sense to focus on Forgejo. It's good to read about the experiences in other projects, but maybe they can be made available somewhere else and only referenced, so interested participants can read them?

mahlzahn commented 2025年06月26日 19:45:35 +02:00

Although I am not a big fan of LLMs and too often I experience them hallucinating, I have to admit that I am using them for developments in Forgejo without disclosure until now. But, my usage is pretty much the one described by @n0toose in #366 (comment).

how to do X and Y in Go?

I found it at least partially helpful to quickly figure out e.g., which libraries can be used, which internal Go functions implement the equivalent to python, which I "speak" more fluently, etc.

Having this said, I'll answer now to the questions, too:

@fnetX wrote in #366 (comment):

• Do we allow the use of generative AI for contributions to Forgejo?

Yes, to some extent I would permit its use. And we cannot even control it.

• I don't want to see descriptions and comments in issues or PRs that were generated by LLM (helping in translation or grammar is fine for me, though). I think that it is essential to the project that all communication is between humans only, because I think it will kill the project when LLMs start talking to each other (seems to have happened here in the past already and wasn't good!).
• I'd accept use of LLMs for minor help. E.g., I could have asked an LLM to check my code for security issues and it would have given the same review comment as @Gusted. Thus, it can be useful as a tool if well handled, like with any tool.

• Which demand do we have regarding transparency on the integration of AI?

I'd welcome transparency about its use, in particular if used substantially.

• What do we expect from contributors who use AI?

Don't use it for any communication. Disclose when and how you used it for more than just searching/learning.

• How do we deal with contributions that do not meet our expectations regarding the usage of AI?

Moderate if repeatedly ignoring our AI rules.

Although I am not a big fan of LLMs and too often I experience them hallucinating, I have to admit that I am using them for developments in Forgejo without disclosure until now. But, my usage is pretty much the one described by @n0toose in https://codeberg.org/forgejo/discussions/issues/366#issuecomment-5610929. > how to do X and Y in Go? I found it at least partially helpful to quickly figure out e.g., which libraries can be used, which internal Go functions implement the equivalent to python, which I "speak" more fluently, etc. Having this said, I'll answer now to the questions, too: @fnetX wrote in https://codeberg.org/forgejo/discussions/issues/366#issue-1886996: > * Do we allow the use of generative AI for contributions to Forgejo? Yes, to some extent I would permit its use. And we cannot even control it. - I don't want to see descriptions and comments in issues or PRs that were generated by LLM (helping in translation or grammar is fine for me, though). I think that it is essential to the project that all communication is between humans only, because I think it will kill the project when LLMs start talking to each other (seems to have happened here in the past already and wasn't good!). - I'd accept use of LLMs for minor help. E.g., I could have asked an LLM to check my code for security issues and it would have given [the same review comment](https://codeberg.org/forgejo/forgejo/pulls/8264/files#issuecomment-5610968) as @Gusted. Thus, it can be useful as a tool if well handled, like with any tool. > * Which demand do we have regarding transparency on the integration of AI? I'd welcome transparency about its use, in particular if used substantially. > * What do we expect from contributors who use AI? Don't use it for any communication. Disclose when and how you used it for more than just searching/learning. > * How do we deal with contributions that do not meet our expectations regarding the usage of AI? Moderate if repeatedly ignoring our AI rules.

earl-warren commented 2025年06月27日 08:33:44 +02:00

@fnetX wrote in #366 (comment):

• Do we allow the use of generative AI for contributions to Forgejo?

I do not think this is something that can be forbidden as there is no way to be sure it is used (except for rare cases that is).

• Which demand do we have regarding transparency on the integration of AI?

IMHO none because, as it was explained here in various ways, the use of AI depends on the person and evolves over time.

• How do we deal with contributions that do not meet our expectations regarding the usage of AI?

Just like any other contribution that does not meet expectations: patience.

• What do we expect from contributors who use AI?

Relying on the idea that most people tell the truth when asked a direct question, I would simply expect them to:

• Give a yes/no answer when asked "have you used AI in this conversation/issue/PR?"
• If the answer is yes and someone asks you to stop using AI in any way to continue this conversation/issue/PR, do it.

In short it relies on managing the undesirable side effects of AI interfering with the Forgejo contribution dynamic by relying on humans trusting each other.

@fnetX wrote in https://codeberg.org/forgejo/discussions/issues/366#issue-1886996: > * Do we allow the use of generative AI for contributions to Forgejo? I do not think this is something that can be forbidden as there is no way to be sure it is used (except for rare cases that is). > * Which demand do we have regarding transparency on the integration of AI? IMHO none because, as it was explained here in various ways, the use of AI depends on the person and evolves over time. > * How do we deal with contributions that do not meet our expectations regarding the usage of AI? Just like any other contribution that does not meet expectations: patience. > * What do we expect from contributors who use AI? Relying on the idea that most people tell the truth when asked a direct question, I would simply expect them to: - Give a yes/no answer when asked "have you used AI in this conversation/issue/PR?" - If the answer is yes and someone asks you to stop using AI in any way to continue this conversation/issue/PR, do it. In short it relies on managing the undesirable side effects of AI interfering with the Forgejo contribution dynamic by relying on humans trusting each other.

n0toose commented 2025年06月27日 10:24:37 +02:00

IMHO none because, as it was explained here in various ways, the use of AI depends on the person and evolves over time.

I think copyright concerns have still not been clarified and that we should avoid tainting the project as much as possible - users should ensure that they have the right to submit whatever they are submitting to us.

---

I think it would be productive to adopt something that others did after they were exposed to a large greater sum of issues / PRs that were AI-assisted or AI-generated (as I said, we should skip the part of the exploration because others have already done it for us). Here are a couple of links:

• cURL: https://curl.se/dev/contribute.html#on-ai-use-in-curl (I really like their approach on differentiating with translations)
• QEMU: https://github.com/qemu/qemu/blob/master/docs/devel/code-provenance.rst#use-of-ai-content-generators
• GNOME's Loupe: https://gitlab.gnome.org/GNOME/loupe/-/blob/main/CONTRIBUTING.md?ref_type=heads#use-of-generative-ai
• Servo: https://book.servo.org/contributing.html#ai-contributions
• Gentoo: https://wiki.gentoo.org/wiki/Project:Council/AI_policy

Here's a couple of excerpts:

We are taking these steps as precaution due to the potential negative influence of AI generated content on quality, as well as likely copyright violations. [Note: This is from GNOME's Loupe.]

Current QEMU project policy is to DECLINE any contributions which are believed to include or derive from AI generated content. This includes ChatGPT, Claude, Copilot, Llama and similar tools.

If you actually find a problem with an AI and you have verified it yourself to be true: write the report yourself and explain the problem as you have learned it. This makes sure the AI-generated inaccuracies and invented issues are filtered out early before they waste more people's time. [Note: This is from curl.]

When contributing content to the curl project, you give us permission to use it as-is and you must make sure you are allowed to distribute it to us. By submitting a change to us, you agree that the changes can and should be adopted by curl and get redistributed under the curl license. [...] We can accept code written with the help of AI into the project, but the code must still follow coding standards [...]

Copyright issues: Publicly available models are trained on copyrighted content, both accidentally and intentionally, and their output often includes that content verbatim. Since the legality of this is uncertain, these contributions may violate the licenses of copyrighted works.

> IMHO none because, as it was explained here in various ways, the use of AI depends on the person and evolves over time. I think copyright concerns have still not been clarified and that we should avoid tainting the project as much as possible - users should *ensure* that they have the right to submit whatever they are submitting to us. --- I think it would be productive to adopt something that others did after they were exposed to a large greater sum of issues / PRs that were AI-assisted or AI-generated (as I said, we should skip the part of the exploration because others have already done it for us). Here are a couple of links: - cURL: https://curl.se/dev/contribute.html#on-ai-use-in-curl (I really like their approach on differentiating with translations) - QEMU: https://github.com/qemu/qemu/blob/master/docs/devel/code-provenance.rst#use-of-ai-content-generators - GNOME's Loupe: https://gitlab.gnome.org/GNOME/loupe/-/blob/main/CONTRIBUTING.md?ref_type=heads#use-of-generative-ai - Servo: https://book.servo.org/contributing.html#ai-contributions - Gentoo: https://wiki.gentoo.org/wiki/Project:Council/AI_policy Here's a couple of excerpts: > We are taking these steps as precaution due to the potential negative influence of AI generated content on quality, as well as likely copyright violations. [Note: This is from GNOME's Loupe.] > Current QEMU project policy is to DECLINE any contributions which are believed to include or derive from AI generated content. This includes ChatGPT, Claude, Copilot, Llama and similar tools. > If you actually find a problem with an AI and you have verified it yourself to be true: write the report yourself and explain the problem as you have learned it. This makes sure the AI-generated inaccuracies and invented issues are filtered out early before they waste more people's time. [Note: This is from curl.] > When contributing content to the curl project, you give us permission to use it as-is and you must make sure you are allowed to distribute it to us. By submitting a change to us, you agree that the changes can and should be adopted by curl and get redistributed under the curl license. [...] We can accept code written with the help of AI into the project, but the code must still follow coding standards [...] > Copyright issues: Publicly available models are trained on copyrighted content, both accidentally and intentionally, and their output often includes that content verbatim. Since the legality of this is uncertain, these contributions may violate the licenses of copyrighted works.

n0toose commented 2025年06月27日 10:29:25 +02:00

To be clear, I moved to Codeberg a few months after having seen my own source code (with the comments!) being suggested back to me during a refactor of a niche, open-source project when AI assistants were very very new, although I have no proof. I think the safeguard-related advancements that have taken place since were, at least in part, motivated to prevent such tools from repeating John Carmack's inverse root square code verbatim - as this would be a threat to an underlying business model.

However, I have tried these tools and totally get why people can use these tools, but I don't think they're often moral. Even when ignoring all of these concerns, they increase churn, produce lots of duplicate code and tons of useless // Add 1 + 1 types of comments.

To be clear, I moved to Codeberg a few months after having seen my own source code (with the comments!) being suggested back to me during a refactor of a niche, open-source project when AI assistants were very very new, although I have no proof. I think the safeguard-related advancements that have taken place since were, at least in part, motivated to prevent such tools from repeating John Carmack's inverse root square code verbatim - as this would be a threat to an underlying business model. However, I have tried these tools and totally get why people can use these tools, but I don't think they're often moral. Even when ignoring all of these concerns, they increase churn, produce lots of duplicate code and tons of useless `// Add 1 + 1` types of comments.

sclu1034 commented 2025年06月27日 10:37:03 +02:00

@earl-warren wrote in #366 (comment):

relying on humans trusting each other

Incidentally, this came up on HN yesterday: https://jaysthoughts.com/aithoughts1

@fnetX wrote in #366 (comment):

• Do we allow the use of generative AI for contributions to Forgejo?

I don't think it would be tenable to completely block it, given that in small-enough snippets, it cannot accurately be distinguished from human-written code.
But it should be made clear to contributors that it should be viewed as one tool in the toolbox, not the driver in the driver's seat.

• Which demand do we have regarding transparency on the integration of AI?

My expectation is that I'm talking to a human, so I would appreciate it if people were transparent when they copy-paste messages wholesale, essentially making me talk to a chatbot in disguise. This includes when they initialize conversations, like in a PR description.

• What do we expect from contributors who use AI?

A contributor should have the same knowledge and understanding of the code they contribute, and the systems involved. If they want to rely on LLMs to generate the code, they should spend extra time to understand that code.
And I believe that adding an "and explain this code" to the prompt is not enough to achieve that.

I also expect that they do not trust their AI's output blindly. They should test and verify its claims, especially the ones it makes in prose, where the test suite cannot help.

• How do we deal with contributions that do not meet our expectations regarding the usage of AI?

Explain our standpoint and process, and ask them to adhere. Explain that we cannot accept their contribution if they are unwilling to comply.

@earl-warren wrote in https://codeberg.org/forgejo/discussions/issues/366#issuecomment-5621063: > relying on humans trusting each other Incidentally, this came up on HN yesterday: https://jaysthoughts.com/aithoughts1 @fnetX wrote in https://codeberg.org/forgejo/discussions/issues/366#issue-1886996: > * Do we allow the use of generative AI for contributions to Forgejo? I don't think it would be tenable to completely block it, given that in small-enough snippets, it cannot accurately be distinguished from human-written code. But it should be made clear to contributors that it should be viewed as one tool in the toolbox, not the driver in the driver's seat. > * Which demand do we have regarding transparency on the integration of AI? My expectation is that I'm talking to a human, so I would appreciate it if people were transparent when they copy-paste messages wholesale, essentially making me talk to a chatbot in disguise. This includes when they initialize conversations, like in a PR description. > * What do we expect from contributors who use AI? A contributor should have the same knowledge and understanding of the code they contribute, and the systems involved. If they want to rely on LLMs to generate the code, they should spend extra time to understand that code. And I believe that adding an "and explain this code" to the prompt is not enough to achieve that. I also expect that they do not trust their AI's output blindly. They should test and verify its claims, especially the ones it makes in prose, where the test suite cannot help. > * How do we deal with contributions that do not meet our expectations regarding the usage of AI? Explain our standpoint and process, and ask them to adhere. Explain that we cannot accept their contribution if they are unwilling to comply.

fnetX commented 2025年06月27日 14:21:31 +02:00

@n0toose thank you for the references. I like the Servo and Gentoo policies, especially the latter. They are on point and highlight the primary issues with AI (quality concerns matter most for me in the context of Forgejo, but the ethical issues in Gentoo are easy to communicate as well).

@n0toose thank you for the references. I like the Servo and Gentoo policies, especially the latter. They are on point and highlight the primary issues with AI (quality concerns matter most for me in the context of Forgejo, but the ethical issues in Gentoo are easy to communicate as well).

pixelcode commented 2025年06月27日 22:28:59 +02:00

I agree that AI shouldn't be a primary tool, but it can be used as a supporting tool (just like you use linters, code completion, etc).

Absolutely! I use LLMs all the time to write code – however, not in the form of "vibe coding" where you actively prompt the AI to do most of the work for you, but almost exclusively in the form of inline suggestions you passively receive from GitHub Copilot. In this sense, LLMs really only provide me with a more intelligent auto-completion.

And I do believe that there is a huge difference between actively prompting the AI to generate large excerpts of code at a time (where you have little influence on the output) vs. passively glancing at an inline suggestions which are highly context-(削除) aware (削除ここまで) appropriate and mostly consist of only a few lines each. In other words, prompting the AI frequently results in generated code which differs significantly from your ideas, whereas inline suggestions have little to no potential to completely throw you off-course, while still speeding up your writing.

By banning AI entirely, such inline auto-complete suggestions would be banned too, which I'd find detrimental.

By the way, LLMs do not have a monopoly on incorrect/misleading suggestions: IntelliJ's non-LLM-powered improvement suggestions and LanguageTool's rule-based grammar-checking are occasionally wrong too, as I have happened to notice.

---

Generally, I would say that it is more important that the code is written in an easy-to-understand way and that it is documented properly, in order to make it easer to be reviewed. The focus should be more on the code itself – whether it does what it is advertised to do – and less on the author, because it's the code that shall be shipped, not its author or their workflow.

> I agree that AI shouldn't be a primary tool, but it can be used as a supporting tool (just like you use linters, code completion, etc). Absolutely! I use LLMs all the time to write code – however, **not** in the form of "vibe coding" where you _**actively prompt**_ the AI to do most of the work for you, but almost exclusively in the form of _**inline suggestions**_ you _**passively receive**_ from GitHub Copilot. In this sense, LLMs really only provide me with a more intelligent auto-completion. And I do believe that there is a huge difference between _actively prompting_ the AI to generate large excerpts of code at a time (where you have little influence on the output) vs. _passively glancing_ at an inline suggestions which are highly context-~aware~ appropriate and mostly consist of only a few lines each. In other words, **prompting** the AI frequently results in generated code which _**differs significantly from your ideas**_, whereas **inline suggestions** have little to no potential to completely throw you off-course, while **_still speeding up_** your writing. By banning AI entirely, such inline auto-complete suggestions would be banned too, which I'd find detrimental. By the way, LLMs do **not** have a monopoly on incorrect/misleading suggestions: IntelliJ's non-LLM-powered improvement suggestions and LanguageTool's rule-based grammar-checking are occasionally wrong too, as I have happened to notice. --- Generally, I would say that it is more important that the code is written in an easy-to-understand way and that it is documented properly, in order to make it easer to be reviewed. The focus should be more on the code itself – whether it does what it is advertised to do – and less on the author, because it's the code that shall be shipped, not its author or their workflow.

n0toose commented 2025年06月27日 22:46:06 +02:00

less on the author, because it's the code that shall be shipped, not its author or their workflow

I don't think this matches my experience in the Forgejo community at all, have you had any different experiences here? IMHO code can't be shipped without the author or their workflow and without an author's ability to communicate with other people.

P.S. Even if this might address quality/critical thinking in one single use case with potential alternatives (but not in many other use cases), I don't think this addresses ethical or copyright concerns.

> less on the author, because it's the code that shall be shipped, not its author or their workflow I don't think this matches my experience in the Forgejo community at all, have you had any different experiences here? IMHO code can't be shipped without the author or their workflow and without an author's ability to communicate with other people. P.S. Even if this might address quality/critical thinking in one single use case with potential alternatives (but not in many other use cases), I don't think this addresses ethical or copyright concerns.

quokka commented 2025年06月27日 23:30:08 +02:00

@pixelcode wrote in #366 (comment):

I agree that AI shouldn't be a primary tool, but it can be used as a supporting tool (just like you use linters, code completion, etc).

Absolutely! I use LLMs all the time to write code – however, not in the form of "vibe coding" where you actively prompt the AI to do most of the work for you, but almost exclusively in the form of inline suggestions you passively receive from GitHub Copilot. In this sense, LLMs really only provide me with a more intelligent auto-completion.

And I do believe that there is a huge difference between actively prompting the AI to generate large excerpts of code at a time (where you have little influence on the output) vs. passively glancing at an inline suggestions which are highly context-(削除) aware (削除ここまで) appropriate and mostly consist of only a few lines each. In other words, prompting the AI frequently results in generated code which differs significantly from your ideas, whereas inline suggestions have little to no potential to completely throw you off-course, while still speeding up your writing.

By banning AI entirely, such inline auto-complete suggestions would be banned too, which I'd find detrimental.

By the way, LLMs do not have a monopoly on incorrect/misleading suggestions: IntelliJ's non-LLM-powered improvement suggestions and LanguageTool's rule-based grammar-checking are occasionally wrong too, as I have happened to notice.

Generally, I would say that it is more important that the code is written in an easy-to-understand way and that it is documented properly, in order to make it easer to be reviewed. The focus should be more on the code itself – whether it does what it is advertised to do – and less on the author, because it's the code that shall be shipped, not its author or their workflow.

Off topic: I looked at your profile and saw the For Good Eyes Only license, which explicitly prohibits causing environmental damage. However, LLMs have a known environmental impact. Does using AI permanently suspend your license?

A lot of the terms of the license are very subjective at best...

@pixelcode wrote in https://codeberg.org/forgejo/discussions/issues/366#issuecomment-5629217: > > I agree that AI shouldn't be a primary tool, but it can be used as a supporting tool (just like you use linters, code completion, etc). > > Absolutely! I use LLMs all the time to write code – however, **not** in the form of "vibe coding" where you _**actively prompt**_ the AI to do most of the work for you, but almost exclusively in the form of _**inline suggestions**_ you _**passively receive**_ from GitHub Copilot. In this sense, LLMs really only provide me with a more intelligent auto-completion. > > And I do believe that there is a huge difference between _actively prompting_ the AI to generate large excerpts of code at a time (where you have little influence on the output) vs. _passively glancing_ at an inline suggestions which are highly context-~aware~ appropriate and mostly consist of only a few lines each. In other words, **prompting** the AI frequently results in generated code which _**differs significantly from your ideas**_, whereas **inline suggestions** have little to no potential to completely throw you off-course, while **_still speeding up_** your writing. > > By banning AI entirely, such inline auto-complete suggestions would be banned too, which I'd find detrimental. > > By the way, LLMs do **not** have a monopoly on incorrect/misleading suggestions: IntelliJ's non-LLM-powered improvement suggestions and LanguageTool's rule-based grammar-checking are occasionally wrong too, as I have happened to notice. > > Generally, I would say that it is more important that the code is written in an easy-to-understand way and that it is documented properly, in order to make it easer to be reviewed. The focus should be more on the code itself – whether it does what it is advertised to do – and less on the author, because it's the code that shall be shipped, not its author or their workflow. Off topic: I looked at your profile and saw the For Good Eyes Only license, which explicitly prohibits causing environmental damage. However, LLMs have [a known environmental impact](https://en.m.wikipedia.org/wiki/Environmental_impact_of_artificial_intelligence). Does using AI permanently suspend your license? A lot of the terms of the license are very subjective at best...

fnetX commented 2025年06月27日 23:31:43 +02:00

@pixelcode Without questioning your experiences, I was not aware that you are a Forgejo contributor, but maybe I missed something. I am sure your comment is valid, but I honestly believe that the needs for code quality and workflow vary greatly between projects, especially for projects at scale. Is there anything you'd like to add that is specific to Forgejo and experiences here?

@pixelcode Without questioning your experiences, I was not aware that you are a Forgejo contributor, but maybe I missed something. I am sure your comment is valid, but I honestly believe that the needs for code quality and workflow vary greatly between projects, especially for projects at scale. Is there anything you'd like to add that is specific to Forgejo and experiences here?

fnetX commented 2025年06月27日 23:34:37 +02:00

For the record, I don't really know if AI inline suggestions are helpful. I don't use an IDE that would support this, and I definitely don't want to use GitHub Copilot for any of my software development. I rely on a 100% free/libre toolchain on my machine, and I try to avoid proprietary AI tools on the web for the same reason.

However, I can't imagine that they save a lot of time. Most of my time goes into thinking about design and architecture, discussing things with others, thinking about the things we did in the past. Writing actual code only makes a small part of my work, and I fear that the potential to save time is really low here. Even if I contributed more code to Forgejo, I have a hard time thinking that things can be speeded up significantly, unless you are not familiar with the languages involved. Which is probably a sign to do something else instead.

For the record, I don't really know if AI inline suggestions are helpful. I don't use an IDE that would support this, and I definitely don't want to use GitHub Copilot for any of my software development. I rely on a 100% free/libre toolchain on my machine, and I try to avoid proprietary AI tools on the web for the same reason. However, I can't imagine that they save a lot of time. Most of my time goes into thinking about design and architecture, discussing things with others, thinking about the things we did in the past. Writing actual code only makes a small part of my work, and I fear that the potential to save time is really low here. Even if I contributed more code to Forgejo, I have a hard time thinking that things can be speeded up significantly, unless you are not familiar with the languages involved. Which is probably a sign to do something else instead.

floss4good commented 2025年06月28日 00:41:26 +02:00

I also don't think that it is feasible to completely disallow the use of generative AI for contributions to Forgejo.

But I would definitely find of common sense to have a rule that such contributions should be marked accordingly when submitted.

The copyright part is more delicate; for this one most probably some policy concerning the permission/license - like in the excerpt from cURL project - would be needed.

I also don't think that it is feasible to completely disallow the use of generative AI for contributions to Forgejo. But I would definitely find of common sense to have a rule that such contributions should be marked accordingly when submitted. The copyright part is more delicate; for this one most probably some policy concerning the permission/license - like in the excerpt from cURL project - would be needed.

pat-s commented 2025年06月28日 09:47:25 +02:00

Upfront: I am not seeking to get "liked" by my views on that topic, especially in this niche community, but I am focused to get/use a "realistic" view of/on the situation rather than using a "romantic"/"it would be nice" one which includes a lot of "maybe"s. So feel free to roast me on this but please also try to see the practical relevance of these and my general motivation to use AI in a "good way" to bring FJ forward as a project.
What I have read so far in this thread is a tendency against the use of AI (in general) with many sentences indicating that a general ban "would be nice" but "is not practicable". I am actually somewhat shocked by this overall tendency and hope this is not going to become the reality. The following points aim to illustrate why:

• Leaving out common patterns and indicators of its use (e.g. the linked PR description pattern), most contribution origins can't be judged and I'd burn my hand that most of the contributions to FJ in the last ~3-6 months contained AI in small or large portions. In the end, the decision is up to the user what is being used to create code. A similar decision has been happening in the 2010s when some projects got mad when users found a solution on SO and c/p that. Wait what? Yes, and in some of my circles this even happened frequently because it was not "their genuine code" but "just c/p from somebody else". These days, nobody cares about this anymore and Stackoverflow-solutions are even considered the "good ones" because the new enemy is now AI. What I want to say with this: while it is romantic, it is unrelastic to assume/hope/wish that every contributor has learned every keystroke that was applied to a diff over many years of study and personal try&errors in their own terminal.
• While AI is quite capable already as of today, it still needs a lot of input/guidance/steering by the user on what to do and what not. So "just using AI" is not that simple and actually also not an issue. Why? The user has to clearly say what the overall goal is, being it when composing a new idea from scratch or when having made initial changes to fine-tune these. Otherwise, the outcome is almost likely wrong, not working, bloat, etc. It is actually a skill these days to use AI so that it creates something meaningful. This might change over time likely, but in a large degree it will likely stay like this.
• There is no clear way that anyone can judge whether the author of a contribution has the potential skills to write a specific complex part of code on their own or not (and hence must have used AI). There are (very) few which can proof historic works of theirs from the pre-AI area, but there will soon be people which just got into the field now and can't even do that. This doesn't mean they couldn't do so in theory, there is just no way they can completely proof that to the public these days anymore without being questioned about this being their own genuine code (without being put into a room without and being watched while typing...). I am including myself into being capable and while that sounds sad to "loose" that
• FJ and other projects with such a large codebase could profit tremendously from this new era. Why? Because these codebases are generally too large for a single person to overlook. And for many larger changes/refactorings etc. a holistic view is needed and many small changes to individual files must be made. The key work of AI here is often not to make the most complex code edits but to know the codebase and being able to quickly link together/look up at which places a change must happen. Even with good IDEs, doing this yourself with a global project search and definition lookups is super hard, error prone and takes hours. AI helps tremendously with these things and opens many doors to tackle ideas people were scared of before due to time/complexity reasons. And to add to that: this especially applies to FJ, as many parts have been written by authors which are not even anymore in the project (Gitea etc) or have only ever touched a very specific subpart of the code. There are only a few, if at all, people that would probably confidentially say that they have an in depth knowledge of the complete code base (which is also not desirable in the first place imo). There are so many parts (left) in FJ to be cleaned up and it doesn't make sense to waste tons of hours to dig into that as a single person, with the high risk of missing elements on the way, rather than thinking about the "what must be done" parts and outsource such complex tasks to AI. This opinion might likely polarize but that's how I see it.

And if the main point is about using proprietary models of non-ethical providers: this is not set in stone and the FOSS com is surely able to provide FLOSS-complicated models that are (1) open and (2) community-curated. Yes, this part is harder than any other task so far given the computing resources needed to accomplish that but surely not impossible.

And in that relation: everyone can choose the model they want to use, there are many out there. And in fact (almost) nobody I know who has looked a few minutes into the field is using GH copilot.

Summary

I am personally fully OK with some practical rules as of

• forcing curated, brief PR descriptions which are at least "largely edited" by the author (again, one cannot judge if bullet point summaries are from AI or not in the end)
• noting that complex code parts were coded by AI, maybe even with a comment in the code so future readers know where this particular complexity came from (-> I don't think there should be an "AI shaming" culture being established)

In the same form as everyone here is following the open culture of FJ/CB in its many forms, I'd also welcome to have an open one on the use of AI alongside some rules for contributions. I really hope there isn't a culture forming where people are "afraid" of using AI due to the fear of getting "roasted" and the main time is then spent on trying to hide its use, so hopefully nobody realizes it.

I also see the danger of the FLOSS community splitting on this topic into FLOSS+AI and FLOSS-AI ones, which IMO would the worst outcome of that debate. I think everyone should aim to avoid this from happening.

Upfront: I am not seeking to get "liked" by my views on that topic, especially in this niche community, but I am focused to get/use a "realistic" view of/on the situation rather than using a "romantic"/"it would be nice" one which includes a lot of "maybe"s. So feel free to roast me on this but please also try to see the practical relevance of these and my general motivation to use AI in a "good way" to bring FJ forward as a project. What I have read so far in this thread is a tendency against the use of AI (in general) with many sentences indicating that a general ban "would be nice" but "is not practicable". I am actually somewhat shocked by this overall tendency and hope this is not going to become the reality. The following points aim to illustrate why: - Leaving out common patterns and indicators of its use (e.g. the linked PR description pattern), most contribution origins can't be judged and I'd burn my hand that *most* of the contributions to FJ in the last ~3-6 months contained AI in small or large portions. In the end, the decision is up to the user what is being used to create code. A similar decision has been happening in the 2010s when some projects got mad when users found a solution on SO and c/p that. Wait what? Yes, and in some of my circles this even happened frequently because it was not "their genuine code" but "just c/p from somebody else". These days, nobody cares about this anymore and Stackoverflow-solutions are even considered the "good ones" because the new enemy is now AI. What I want to say with this: while it is romantic, it is unrelastic to assume/hope/wish that every contributor has learned every keystroke that was applied to a diff over many years of study and personal try&errors in their own terminal. - While AI is quite capable already as of today, it still needs *a lot* of input/guidance/steering by the user on *what to do* and what not. So "just using AI" is not that simple and actually also not an issue. *Why*? The user has to clearly say what the overall goal is, being it when composing a new idea from scratch or when having made initial changes to fine-tune these. Otherwise, the outcome is almost likely wrong, not working, bloat, etc. **It is actually a skill these days to use AI** so that it creates something meaningful. This might change over time likely, but in a large degree it will likely stay like this. - There is no clear way that anyone can judge whether the author of a contribution has the potential skills to write a specific complex part of code on their own or not (and hence must have used AI). There are (very) few which can proof historic works of theirs from the pre-AI area, but there will soon be people which just got into the field now and can't even do that. This doesn't mean they couldn't do so in theory, there is just no way they can *completely* proof that to the public these days anymore without being questioned about this being their own genuine code (without being put into a room without and being watched while typing...). I am including myself into being capable and while that sounds sad to "loose" that - FJ and other projects with such a large codebase could profit tremendously from this new era. *Why*? Because these codebases are generally too large for a single person to overlook. And for many larger changes/refactorings etc. a holistic view is needed and many small changes to individual files must be made. The key work of AI here is often not to make the most complex code edits but to know the codebase and being able to quickly link together/look up at which places a change must happen. Even with good IDEs, doing this yourself with a global project search and definition lookups is super hard, error prone and takes hours. AI helps tremendously with these things and opens many doors to tackle ideas people were scared of before due to time/complexity reasons. And to add to that: this especially applies to FJ, as many parts have been written by authors which are not even anymore in the project (Gitea etc) or have only ever touched a very specific subpart of the code. There are only a few, if at all, people that would probably confidentially say that they have an *in depth* knowledge of the *complete* code base (which is also not desirable in the first place imo). There are so many parts (left) in FJ to be cleaned up and it doesn't make sense to waste tons of hours to dig into that as a single person, with the high risk of missing elements on the way, rather than thinking about the "what must be done" parts and outsource such complex tasks to AI. This opinion might likely polarize but that's how I see it. And if the main point is about using proprietary models of non-ethical providers: this is not set in stone and the FOSS com is surely able to provide FLOSS-complicated models that are (1) open and (2) community-curated. Yes, this part is harder than any other task so far given the computing resources needed to accomplish that but surely not impossible. And in that relation: everyone can choose the model they want to use, there are many out there. And in fact (almost) nobody I know who has looked a few minutes into the field is using GH copilot. ### Summary I am personally fully OK with some practical rules as of - forcing curated, brief PR descriptions which are at least "largely edited" by the author (again, one cannot judge if bullet point summaries are from AI or not in the end) - noting that complex code parts were coded by AI, maybe even with a comment in the code so future readers know where this particular complexity came from (-> I don't think there should be an "AI shaming" culture being established) In the same form as everyone here is following the open culture of FJ/CB in its many forms, I'd also welcome to have an open one on the use of AI alongside some rules for contributions. I *really hope* there isn't a culture forming where people are "afraid" of using AI due to the fear of getting "roasted" and the main time is then spent on trying to hide its use, so hopefully nobody realizes it. I also see the danger of the FLOSS community splitting on this topic into FLOSS+AI and FLOSS-AI ones, which IMO would the worst outcome of that debate. I think everyone should aim to avoid this from happening.

fogti commented 2025年06月28日 11:51:32 +02:00

It is actually a skill these days to use AI

Unfortunately, just like with vendor lock-in with vendors that regularly trash most of their APIs, it isn't (yet?) a skill that doesn't bit-rot away (and can do so in an unpredictable manner, because albeit AI interfaces having some versioning, old versions often don't stay usable for long, and vendors still occasionally change stuff even without publishing a new version). This wouldn't be much of a problem with actually completely FLOSS models (including the complete training set being open and training pipeline being open (reproducibility would be nice, but is way harder / unrealistic), but these seem pretty far away.

In regards to the last point "FJ and other projects [...]": This is a point which I think you overestimate in complexity, because I had to do such a thing quite frequently in the past, and I don't even use an IDE most of the time, instead, I mostly rely on compiler errors and autogenerated documentation to find stuff, and it works quite well, and if not, if a project has a sensible enough naming convention, a quick grep/rg invocation pretty often also gets the job done (even beyond items that are linked in a sense that a compiler/LSP or such understands). (disclosure: the only "substantial" contribution I did for/to forgejo was building https://codeberg.org/forgejo/forgejo/src/branch/forgejo/build/lint-locale-usage from scratch)

> It is actually a skill these days to use AI Unfortunately, just like with vendor lock-in with vendors that regularly trash most of their APIs, it isn't (yet?) a skill that doesn't bit-rot away (and can do so in an unpredictable manner, because albeit AI interfaces having some versioning, old versions often don't stay usable for long, and vendors still occasionally change stuff even without publishing a new version). This wouldn't be much of a problem with actually completely FLOSS models (including the complete training set being open and training pipeline being open (reproducibility would be nice, but is way harder / unrealistic), but these seem pretty far away. In regards to the last point "FJ and other projects [...]": This is a point which I think you overestimate in complexity, because I had to do such a thing quite frequently in the past, and I don't even use an IDE most of the time, instead, I mostly rely on compiler errors and autogenerated documentation to find stuff, and it works quite well, and if not, if a project has a sensible enough naming convention, a quick `grep`/`rg` invocation pretty often also gets the job done (even beyond items that are linked in a sense that a compiler/LSP or such understands). (disclosure: the only "substantial" contribution I did for/to forgejo was building https://codeberg.org/forgejo/forgejo/src/branch/forgejo/build/lint-locale-usage from scratch)

viceice commented 2025年06月28日 12:15:38 +02:00

i also use AI auto complete suggestions from my ide. I'm using GitHub copilot (I've got free license for my work as renovate maintainer). it's helping me a lot when writing tests because they often have a similar structure.

I'm also working (coding) on projects (closed source) where AI is completely disallowed and there I really miss the AI auto complete, su I'm less productive there because I need a lot more time to write test code.

for normal production code ai isn't much helpful because it mostly doesn't know what you like to do (because it's not well trained with the existing code)

i also use AI auto complete suggestions from my ide. I'm using GitHub copilot (I've got free license for my work as renovate maintainer). it's helping me a lot when writing tests because they often have a similar structure. I'm also working (coding) on projects (closed source) where AI is completely disallowed and there I really miss the AI auto complete, su I'm less productive there because I need a lot more time to write test code. for normal production code ai isn't much helpful because it mostly doesn't know what you like to do (because it's not well trained with the existing code)

pat-s commented 2025年06月28日 13:45:07 +02:00

for normal production code ai isn't much helpful because it mostly doesn't know what you like to do (because it's not well trained with the existing code)

If you have ever only used copilot so far, I can understand that view. Yet this does not apply to other models. Have a look at the Claude models or Cursor (the app) and you might change your view on that.
In the end, the model must have the permissions and capabilities to index the local codebase. Then it can do really powerful things. Providing individual files as a context isn't of much help for "broader" tasks and even for individual files changes it often doesn't take into account the syntax used in other files, which then leads to an async solution that "feels wrong". A good model, which knows the codebase, is aware of these patterns and can create solutions which seamlessly integrate with the current codebase structures.

> for normal production code ai isn't much helpful because it mostly doesn't know what you like to do (because it's not well trained with the existing code) If you have ever only used copilot so far, I can understand that view. Yet this does not apply to other models. Have a look at the Claude models or Cursor (the app) and you might change your view on that. In the end, the model must have the permissions and capabilities to index the local codebase. Then it can do really powerful things. Providing individual files as a context isn't of much help for "broader" tasks and even for individual files changes it often doesn't take into account the syntax used in other files, which then leads to an async solution that "feels wrong". A good model, which knows the codebase, is aware of these patterns and can create solutions which seamlessly integrate with the current codebase structures.

sclu1034 commented 2025年06月28日 14:26:06 +02:00

@pat-s wrote in #366 (comment):

Yes, and in some of my circles this even happened frequently because it was not "their genuine code" but "just c/p from somebody else". These days, nobody cares about this anymore and Stackoverflow-solutions are even considered the "good ones" because the new enemy is now AI.

I doubt that those circles call it "good" now, but rather "lesser evil".
If I had to choose between a house or a garden shed burning down, I'd know what I'd pick. But that doesn't mean the shed burning down has become a good thing, it's just less bad.

@pat-s wrote in #366 (comment):

assume/hope/wish that every contributor has learned every keystroke that was applied to a diff over many years of study and personal try&errors

Please refrain from disingenuous exaggerations. Neither in spirit nor in words is this close to what has been said so far.

@pat-s wrote in #366 (comment):

The user has to clearly say what the overall goal is, being it when composing a new idea from scratch or when having made initial changes to fine-tune these. Otherwise, the outcome is almost likely wrong, not working, bloat, etc. It is actually a skill these days to use AI

It's enough of a skill to warrant job titles like "Prompt Engineer", but I have yet to see evidence for the sentiment that it should be capable of replacing the expertise of a "Software Engineer".
As you say, "[the] user has to clearly say what the overall goal is". And the issue is that it's also where the user stops. They prompt for "what", but ignore the "how".
However, the details are what make the expertise in a software engineer, and the details are what make the quality of a contribution. And AI's shortcomings in those details are why it's output is generally regarded to be on the same level as a junior (read: inexperienced) engineer.

AI is a tool, and the user's understanding and mindset of its usage determine the outcome. For example: Colloquially, a hammer might be considered "a tool to put nails in the wall". But that's not what a hammer is.
It's a tool that multiplies a force. Direction, angle, position and strength (i.e. the details) are all variables that the user needs to provide.
If I were to attach a motor and a nail dispenser to a hammer with some statistically plausible values for those variables, I could let it go ham on a wall all by its own, but the result would very likely be crooked nails and dents in the wall.

Similarly, AI is still not even close to a place where you can "let it go ham" on a software engineering problem, even if you "clearly say what the overall goal is". The outcome is just as crooked and cracked. As a tool, it does not amplify your expertise, only your typing speed.

Of course, in businesses that focus on time to value and don't care much how things work beyond the fact that they do, the lack of details is fine. The customer doesn't get to see the crooked nails on the inside walls, after all.
But in open source, we still have the luxury to focus on quality over quantity, and in my experience reliance on AI simply cannot deliver that. Doubly so if contributors attempt to use it to punch above their weight class.

@pat-s wrote in #366 (comment):

There is no clear way that anyone can judge whether the author of a contribution has the potential skills to write a specific complex part of code on their own or not (and hence must have used AI).

There might not be deterministic processes you can apply to get a clear yes/no. But approximations and hunches are enough to to start paying more attention and to figure things out over time. Especially the people that rely too heavily on AI alone will eventually end up being too eager.

Except for small snippets (such as that regexp mentioned in an earlier message), and combined with the back and forth that a review on a complex contribution would entail, I expect it to come out eventually. Especially the further the gap between the problem and the expertise.

And once it has become apparent that there is a gap in expertise between the code and its contributor, that's when it becomes a problem, because the burden on the reviewers has now skyrocketed.

@pat-s wrote in #366 (comment):

AI helps tremendously with these things and opens many doors to tackle ideas people were scared of before due to time/complexity reasons

I consider this a false sense of security. As already established above, AI's output cannot be trusted blindly. It may be faster in finding places that need to be touched in a given refactor, but it's neither guaranteed to find all of them, nor that its changes are correct.
So even with AI, you need to verify every change made, and need to check for missing changes and do them manually.

Tools that give you actual security in refactors are deterministic ones, like compilers, linters and test coverage.

@pat-s wrote in https://codeberg.org/forgejo/discussions/issues/366#issuecomment-5633492: > Yes, and in some of my circles this even happened frequently because it was not "their genuine code" but "just c/p from somebody else". These days, nobody cares about this anymore and Stackoverflow-solutions are even considered the "good ones" because the new enemy is now AI. I doubt that those circles call it "good" now, but rather "lesser evil". If I had to choose between a house or a garden shed burning down, I'd know what I'd pick. But that doesn't mean the shed burning down has become a good thing, it's just less bad. @pat-s wrote in https://codeberg.org/forgejo/discussions/issues/366#issuecomment-5633492: > assume/hope/wish that every contributor has learned every keystroke that was applied to a diff over many years of study and personal try&errors Please refrain from disingenuous exaggerations. Neither in spirit nor in words is this close to what has been said so far. @pat-s wrote in https://codeberg.org/forgejo/discussions/issues/366#issuecomment-5633492: > The user has to clearly say what the overall goal is, being it when composing a new idea from scratch or when having made initial changes to fine-tune these. Otherwise, the outcome is almost likely wrong, not working, bloat, etc. It is actually a skill these days to use AI It's enough of a skill to warrant job titles like "Prompt Engineer", but I have yet to see evidence for the sentiment that it should be capable of replacing the expertise of a "Software Engineer". As you say, "[the] user has to clearly say what the overall goal is". And the issue is that it's also where the user stops. They prompt for "what", but ignore the "how". However, the details are what make the expertise in a software engineer, and the details are what make the quality of a contribution. And AI's shortcomings in those details are why it's output is generally regarded to be on the same level as a junior (read: inexperienced) engineer. AI is a tool, and the user's understanding and mindset of its usage determine the outcome. For example: Colloquially, a hammer might be considered "a tool to put nails in the wall". But that's not what a hammer is. It's a tool that multiplies a force. Direction, angle, position and strength (i.e. the details) are all variables that the user needs to provide. If I were to attach a motor and a nail dispenser to a hammer with some statistically plausible values for those variables, I could let it go ham on a wall all by its own, but the result would very likely be crooked nails and dents in the wall. Similarly, AI is still not even close to a place where you can "let it go ham" on a software engineering problem, even if you "clearly say what the overall goal is". The outcome is just as crooked and cracked. As a tool, it does not amplify your expertise, only your typing speed. Of course, in businesses that focus on time to value and don't care much how things work beyond the fact that they do, the lack of details is fine. The customer doesn't get to see the crooked nails on the inside walls, after all. But in open source, we still have the luxury to focus on quality over quantity, and in my experience reliance on AI simply cannot deliver that. Doubly so if contributors attempt to use it to punch above their weight class. @pat-s wrote in https://codeberg.org/forgejo/discussions/issues/366#issuecomment-5633492: > There is no clear way that anyone can judge whether the author of a contribution has the potential skills to write a specific complex part of code on their own or not (and hence must have used AI). There might not be deterministic processes you can apply to get a clear yes/no. But approximations and hunches are enough to to start paying more attention and to figure things out over time. Especially the people that rely too heavily on AI alone will eventually end up being too eager. Except for small snippets (such as that regexp mentioned in an earlier message), and combined with the back and forth that a review on a complex contribution would entail, I expect it to come out eventually. Especially the further the gap between the problem and the expertise. And once it has become apparent that there is a gap in expertise between the code and its contributor, that's when it becomes a problem, because the burden on the reviewers has now skyrocketed. @pat-s wrote in https://codeberg.org/forgejo/discussions/issues/366#issuecomment-5633492: > AI helps tremendously with these things and opens many doors to tackle ideas people were scared of before due to time/complexity reasons I consider this a false sense of security. As already established above, AI's output cannot be trusted blindly. It may be faster in finding places that need to be touched in a given refactor, but it's neither guaranteed to find all of them, nor that its changes are correct. So even with AI, you need to verify every change made, and need to check for missing changes and do them manually. Tools that give you actual security in refactors are deterministic ones, like compilers, linters and test coverage.

earl-warren commented 2025年06月28日 22:05:41 +02:00

This is a very insightful discussion and I'm learning a lot 🙏 I won't use AI for now because I only use Free Software tools. But, as @pat-s suggests, there may be Free Software tools and data models in the future and I would use those for the benefits described by @viceice and others.

Philosophically I'm a close to @sclu1034, @n0toose and @fnetX (if that was not already obvious 😁) and when I write it may be perceived as me being hostile to AI as a concept. I'm not. I'm actively working on Forgejo so nothing in my daily activity depends on proprietary software. But this is a personal stance and not something I will impose on others. If someone is using Microsoft or Apple products, I feel for them because they are not in control of their tools but I will not condemn them: they are victims and should not be shamed or criticized for it.

With that in mind, I also expect others won't push me to use or work with anything that is not Free Software, directly or indirectly. As a contributor to Forgejo, I am yet to be significantly inconvenienced by how AI transforms my relationship with other people. There have been a few episodes but nothing really disruptive. But this is growing and I welcome this discussion to find clarity on how to deal with it.

@sclu1034 pointed to https://jaysthoughts.com/aithoughts1 which I enjoyed reading and explains better than I can that the discourse around AI in Forgejo should be focused on minimizing its impact on how trust is built in the community.

This is a very insightful discussion and I'm learning a lot 🙏 I won't use AI for now because I only use Free Software tools. But, as @pat-s suggests, there may be Free Software tools and data models in the future and I would use those for the benefits described by @viceice and others. Philosophically I'm a close to @sclu1034, @n0toose and @fnetX (if that was not already obvious 😁) and when I write it may be perceived as me being hostile to AI as a concept. I'm not. I'm actively working on Forgejo so nothing in my daily activity depends on proprietary software. But this is a personal stance and not something I will impose on others. If someone is using Microsoft or Apple products, I feel for them because they are not in control of their tools but I will not condemn them: they are victims and should not be shamed or criticized for it. With that in mind, I also expect others won't push me to use or work with anything that is not Free Software, directly or indirectly. As a contributor to Forgejo, I am yet to be significantly inconvenienced by how AI transforms my relationship with other people. There have been a few episodes but nothing really disruptive. But this is growing and I welcome this discussion to find clarity on how to deal with it. @sclu1034 pointed to https://jaysthoughts.com/aithoughts1 which I enjoyed reading and explains better than I can that the discourse around AI in Forgejo should be focused on minimizing its impact on how trust is built in the community.

fnetX commented 2025年06月28日 23:27:33 +02:00

Tools that give you actual security in refactors are deterministic ones

I think this is a very important detail, and I'd love to get more automated assistance that just behaves the way someone designed it.

> Tools that give you actual security in refactors are deterministic ones I think this is a very important detail, and I'd love to get more automated assistance that just behaves the way someone designed it.

n0toose commented 2025年06月29日 02:33:10 +02:00

I'd love to get more automated assistance that just behaves the way someone designed it.

they are not in control of their tools but I will not condemn them

+1, I really believe that AI tools are popular as 'search engines' because searching the SEO-optimized Internet in the year 2025 is godawful. I think improving our documentation and tooling (like in the way @fogti explicitly did in an earlier PR) is a way to go. I mentioned a few cases earlier like that myself.

there may be Free Software tools and data models in the future

I don't think a policy represents permanence; I think we've had a track record of revisiting previous decisions if they stop making sense, therefore I don't really see the potential of improvement in agentic AI as an argument against a policy at least as strong as that of cURL (which is the mildest one I could find). People say a lot of things about AI, but the truth is that we are in the present and not in any TESCREAL-invented state of emergency, nor are we in utopian parallel universe in which AI can cook you an omelette and do your laundry while curing some niche form of cancer, all at the same time. Although I would explicitly not be opposed to free software tools and data models (although currently a controversial subject on its own), it's not worth discussing because we'd be talking about regulating something abstract that doesn't exist yet - it would be a distraction at best.

There were a lot of arguments that kind of came across like this to me: "Just because people can shoplift gummy erasers, there's not much sense in making any sense in crafting a policy that tells people not to steal anything (including the refrigerators and laptops)"... although I later found that some probably meant "there's not much sense in crafting a policy that bans everything" instead, otherwise I'd find that disappointingly cynical.

> I'd love to get more automated assistance that just behaves the way someone designed it. > they are not in control of their tools but I will not condemn them +1, I really believe that AI tools are popular as 'search engines' because searching the SEO-optimized Internet in the year 2025 is godawful. I think improving our documentation and tooling (like in the way @fogti explicitly did in an earlier PR) is a way to go. I mentioned a few cases earlier like that myself. > there may be Free Software tools and data models in the future I don't think a policy represents permanence; I think we've had a track record of revisiting previous decisions if they stop making sense, therefore I don't really see the potential of improvement in agentic AI as an argument against a policy at least as strong as that of cURL (which is the mildest one I could find). People say a lot of things about AI, but the truth is that we are in the present and not in any [TESCREAL](https://en.wikipedia.org/wiki/TESCREAL)-invented state of emergency, nor are we in utopian parallel universe in which AI can cook you an omelette and do your laundry while curing some niche form of cancer, all at the same time. Although I would explicitly *not* be opposed to free software tools and data models (although currently a controversial subject on its own), it's not worth discussing because we'd be talking about regulating something abstract that doesn't exist yet - it would be a distraction at best. There were a lot of arguments that kind of came across like this to me: "Just because people can shoplift gummy erasers, there's not much sense in making any sense in crafting a policy that tells people not to steal anything (including the refrigerators and laptops)"... although I later found that some probably meant "there's not much sense in crafting a policy that bans *everything*" instead, otherwise I'd find that disappointingly cynical.

earl-warren commented 2025年06月29日 08:36:36 +02:00

... it's not worth discussing because we'd be talking about regulating something abstract that doesn't exist yet ...

I agree it would be wrong to base present actions on an hypothetical future. I meat what I wrote ("there may be Free Software tools and data models in the future and I'll use them") to clarify that I don't have anything against AI as a concept. I have issues with how it is currently implemented (100% controlled by a handful of large companies).

> ... it's not worth discussing because we'd be talking about regulating something abstract that doesn't exist yet ... I agree it would be wrong to base present actions on an hypothetical future. I meat what I wrote ("there may be Free Software tools and data models in the future and I'll use them") to clarify that I don't have anything against AI as a concept. I have issues with how it is currently implemented (100% controlled by a handful of large companies).

Gusted commented 2025年07月09日 23:22:37 +02:00

@fnetX wrote in #366 (comment):

Do we allow the use of generative AI for contributions to Forgejo?

Does this include dependencies that were made via generative AI? Or where the current process is to have new code reviewed by AI review bots?

Random examples from the top of my head:

• https://github.com/SaveTheRbtz/zstd-seekable-format-go/pull/204 (reference to ChatGPT codex).
• https://github.com/go-webauthn/webauthn/pull/434 (uses Coderabbit AI as part of their review).

More specifically does this impact code that is reviewed, created and maintained within Forgejo spaces or does this also include what Forgejo outputs such as the Forgejo binary?

@fnetX wrote in https://codeberg.org/forgejo/discussions/issues/366#issue-1886996: > Do we allow the use of generative AI for contributions to Forgejo? Does this include dependencies that were made via generative AI? Or where the current process is to have new code reviewed by AI review bots? Random examples from the top of my head: - https://github.com/SaveTheRbtz/zstd-seekable-format-go/pull/204 (reference to [ChatGPT codex](https://chatgpt.com/codex)). - https://github.com/go-webauthn/webauthn/pull/434 (uses [Coderabbit AI](https://www.coderabbit.ai/) as part of their review). More specifically does this impact code that is reviewed, created and maintained within Forgejo spaces or does this also include what Forgejo outputs such as the Forgejo binary?

fnetX commented 2025年07月09日 23:34:50 +02:00

My goal was to get the discussion started, mostly for the Forgejo spaces. For the inclusion of dependencies, I hope that we'll do some due diligence checking that they are maintained carefully. I would hope that "vibe-coded" libraries without proper human oversight don't make it into Forgejo easily, whereas I don't object to having other projects experiment and use generative AI.

My goal was to get the discussion started, mostly for the Forgejo spaces. For the inclusion of dependencies, I hope that we'll do some due diligence checking that they are maintained carefully. I would hope that "vibe-coded" libraries without proper human oversight don't make it into Forgejo easily, whereas I don't object to having other projects experiment and use generative AI.

Gusted commented 2025年07月12日 15:52:47 +02:00

Hi everyone,

It has been 2 weeks since @fnetX opened this discussion and I feel that most opinions and perspectives have been voiced by now. I feel this is a controversial, although important, topic and I would like this discussion to reach a conclusion. Therefore, I will start the decision-making process.

I will be using the guidance of the decision-making process that is documented in Forgejo's government repository, specifically "Process for more complex or controversial decisions". I would say that this discussion fulfills the first, second and third steps ¹ .

The next step forward is for people to write proposals. I see two kinds of proposals that can conclude this discussion: one where the use of AI will not be allowed in Forgejo and the other where the use of AI will be allowed in Forgejo.

The decision-making process says to wait a few days for people to write a proposal. I feel this is too little time for anyone who wants to write a serious proposal about this topic and, as such, I will say that all proposals should be in by 26 July. After that, step 5 will start.

If you have plans to write a proposal, I suggest posting that you want to write one and from which perspective, so people will not write similar proposals; this might also invite people to collaborate on writing a proposal. As a word of advice, it is worth reading the bits on what a good proposal includes in the decision-making process document. Post your final proposal in this issue and not on the governance repository, as this will be done on 26 July.

I have a clear bias on this topic, therefore I will write a proposal where the use of AI is denied in Forgejo.

If you have any questions or disagreements with this, please state so here or privately to me and I will try my best to address them.

Hi everyone, It has been 2 weeks since @fnetX opened this discussion and I feel that most opinions and perspectives have been voiced by now. I feel this is a controversial, although important, topic and I would like this discussion to reach a conclusion. Therefore, I will start the decision-making process. I will be using the guidance of [the decision-making process](https://codeberg.org/forgejo/governance/src/branch/main/DECISION-MAKING.md) that is documented in Forgejo's government repository, specifically "Process for more complex or controversial decisions". I would say that this discussion fulfills the first, second and third steps [^1]. [^1]: This discussion posed several open-inclusive decision questions, which fulfills the first step. People have given their opinions and thoughts on to what extent AI should be allowed from both sides, which fulfills the second and third steps. The next step forward is for people to write proposals. I see two kinds of proposals that can conclude this discussion: one where the use of AI will not be allowed in Forgejo and the other where the use of AI will be allowed in Forgejo. The decision-making process says to wait a few days for people to write a proposal. I feel this is too little time for anyone who wants to write a serious proposal about this topic and, as such, I will say that **all proposals should be in by 26 July**. After that, step 5 will start. If you have plans to write a proposal, I suggest posting that you want to write one and from which perspective, so people will not write similar proposals; this might also invite people to collaborate on writing a proposal. As a word of advice, it is worth reading the bits on what a good proposal includes [in the decision-making process document](https://codeberg.org/forgejo/governance/src/branch/main/DECISION-MAKING.md). **Post your final proposal in this issue** and not on the governance repository, as this will be done on 26 July. I have a clear bias on this topic, therefore I will write a proposal where the use of AI is denied in Forgejo. If you have any questions or disagreements with this, please state so here or privately to me and I will try my best to address them.

earl-warren commented 2025年07月12日 17:19:46 +02:00

I have a clear bias on this topic, therefore I will write a proposal where the use of AI is denied in Forgejo.

I look forward to your proposal. I also absolutely oppose the notion that an AI with no human attached to it becomes a contributor. That would be an horrible experience. On the other hand I also know a lot of good humans who have an AI in their toolbox and use it daily. I would not want those good people to feel they are cast aside because of that.

How to reach a decision that is a good middleground is something I can't quite figure out.

@earl-warren wrote in #366 (comment):

Relying on the idea that most people tell the truth when asked a direct question, I would simply expect them to:

• Give a yes/no answer when asked "have you used AI in this conversation/issue/PR?"
• If the answer is yes and someone asks you to stop using AI in any way to continue this conversation/issue/PR, do it.

In short it relies on managing the undesirable side effects of AI interfering with the Forgejo contribution dynamic by relying on humans trusting each other.

This is the best I could think of and although it would make for a simple and straightforward proposal I'm not convinced it would actually work.

> I have a clear bias on this topic, therefore I will write a proposal where the use of AI is denied in Forgejo. I look forward to your proposal. I also absolutely oppose the notion that an AI with no human attached to it becomes a contributor. That would be an horrible experience. On the other hand I also know a lot of good humans who have an AI in their toolbox and use it daily. I would not want those good people to feel they are cast aside because of that. How to reach a decision that is a good middleground is something I can't quite figure out. @earl-warren wrote in https://codeberg.org/forgejo/discussions/issues/366#issuecomment-5621063: > Relying on the idea that most people tell the truth when asked a direct question, I would simply expect them to: > > * Give a yes/no answer when asked "have you used AI in this conversation/issue/PR?" > * If the answer is yes and someone asks you to stop using AI in any way to continue this conversation/issue/PR, do it. > > > In short it relies on managing the undesirable side effects of AI interfering with the Forgejo contribution dynamic by relying on humans trusting each other. This is the best I could think of and although it would make for a simple and straightforward proposal I'm not convinced it would actually work.

fnetX commented 2025年07月13日 18:23:56 +02:00

I'll split my proposals into smaller chunks that can be decided on independently.

The first proposal addresses the needs for

• Transparency: We need to evaluate the usage of "AI" in Forgejo and learn more about the effects.
• Consent: Contributors in Forgejo need a way to decide not to deal with AI content (e.g. refusing reviews or triaging issues when AI was involved).

---

Contributors who submit work to Forgejo that was generated using the help of large language models (LLM, also commonly referred to as "AI") must disclose their usage in appropriate places. It is necessary to include at least the scope of the support and the list of used tools / models. The only exception is using machine-learning based translation tools.

"Submitted work" includes all content submitted to Forgejo: Text in issues, pull requests and their comments; code changes and their respective commit messages; blog posts and documentation; messages posted in Forgejo chatrooms.

"Appropriate places" are places that are clearly linked to the submitted content and can be looked up in both directions (e.g. using git blame). For issue and PR conversation, the mention must be preceding the generated content. For code changes, a mention needs to be placed prominently in the commit message and PR description.

The exception for translations only includes translating text into another language verbatim, when the used tools do not change meaning or suggest content. For example, asking an AI to generate a translated text from notes cannot be considered for the exception.

I'll split my proposals into smaller chunks that can be decided on independently. The first proposal addresses the needs for * Transparency: We need to evaluate the usage of "AI" in Forgejo and learn more about the effects. * Consent: Contributors in Forgejo need a way to decide not to deal with AI content (e.g. refusing reviews or triaging issues when AI was involved). --- Contributors who submit work to Forgejo that was generated using the help of large language models (LLM, also commonly referred to as "AI") must disclose their usage in appropriate places. It is necessary to include at least the scope of the support and the list of used tools / models. The only exception is using machine-learning based translation tools. "Submitted work" includes all content submitted to Forgejo: Text in issues, pull requests and their comments; code changes and their respective commit messages; blog posts and documentation; messages posted in Forgejo chatrooms. "Appropriate places" are places that are clearly linked to the submitted content and can be looked up in both directions (e.g. using `git blame`). For issue and PR conversation, the mention must be preceding the generated content. For code changes, a mention needs to be placed prominently in the commit message and PR description. The exception for translations only includes translating text into another language verbatim, when the used tools do not change meaning or suggest content. For example, asking an AI to generate a translated text from notes cannot be considered for the exception.

fnetX commented 2025年07月13日 18:27:05 +02:00

Another proposal that addresses the informal part of how we deal with each other in Forgejo spaces.

---

The Forgejo community acknowledges that using AI tools for code and communication can place a significant burden on other community members. We refrain from using AI tools to generate large amounts of content that need to be consumed by other humans, and respect the decision of others to not be involved with such content.

Another proposal that addresses the informal part of how we deal with each other in Forgejo spaces. --- The Forgejo community acknowledges that using AI tools for code and communication can place a significant burden on other community members. We refrain from using AI tools to generate large amounts of content that need to be consumed by other humans, and respect the decision of others to not be involved with such content.

fnetX commented 2025年07月13日 18:30:38 +02:00

And, last but not least: A way to escape AI hell if there is a lot of such content.

---

If the amount of AI generated content is increasing, the Forgejo community seeks a way to mark AI-generated code in a standard way (e.g. using labels or standard commit headers), to give contributors a way to filter content.

If content is not marked as being AI-generated, but is suspected to be, the label can be added as a warning for other community members as well.

And, last but not least: A way to escape AI hell if there is a lot of such content. --- If the amount of AI generated content is increasing, the Forgejo community seeks a way to mark AI-generated code in a standard way (e.g. using labels or standard commit headers), to give contributors a way to filter content. If content is not marked as being AI-generated, but is suspected to be, the label can be added as a warning for other community members as well.

earl-warren commented 2025年07月18日 22:06:17 +02:00

For the record, there is a suspicion of AI only generated content at forgejo/forgejo#8566.

For the record, there is a suspicion of AI only generated content at https://codeberg.org/forgejo/forgejo/issues/8566.

Gusted commented 2025年07月19日 22:54:58 +02:00

As I announced a week ago, hereby my proposal. As a reminder, all proposals that want to be considered for this discussion have to be submitted by next week 26 July in this issue.

Forgejo AI agreement proposal

This is a proposal in response to the discussion on the usage of AI in Forgejo.
This proposal seeks to heavily restrict the usage of AI in Forgejo in a pragmatic manner.

Background

Terminology

The following explains terminology that is used in this proposal, but does not necessarily reflect the official or commonly used terminology.

Software and services that heavily rely on large language model technology to generate their outcomes are referred to as Artificial Intelligence (AI). Examples of products that fit this definition: GitHub Copilot, ChatGPT, Claude Sonnet, DeepSeek, Llama and Gemini.

There's a distinction between general and narrow AI, all the aforementioned examples fall under general AI as they were not trained to execute a specific well-defined task. Narrow AI is trained to be used for specific well-defined tasks where the problem space is known in advance, an example is given in the last paragraph in the code review section.

Aim

The aim of this proposal is to have a set of agreements that clarifies and give guidance for the usage of AI in any repository that falls under Forgejo's governance¹ . Specifically it seeks to maximize the following five points:

1. It should be clear to any contributor in what way AI can and cannot be used in their contribution to Forgejo.
2. It should be clear to any contributor what their responsibility is when they choose to use AI for their contribution to Forgejo.
3. It should be clear to any reviewer of the code in what way and to which significance AI was used in the creation of a code change and communication.
4. It should be clear to people (considering) using Forgejo how AI is used in Forgejo's development.
5. There's clear guidance on how to deal with violations of the proposed agreements in this proposal.

Current situation

Within the FOSS community, policies have been adopt that ban AI over concerns of quality, licensing and ecological reasons.²

People have chosen Forgejo over other forges as it is not being invested with AI features³ and I strongly believe they would dislike seeing AI being used for Forgejo's development.

FOSS projects that have accepted the use of AI contributions (or integrated AI features) have not been received well within the FOSS community; going on the record that you allow AI does not reflect well on the project.⁴

Agreement

Before explaining the rationale behind the agreements, these are the exact agreements I propose:

1. If content was made with the help of AI, you must convey that this is the case. This includes content that you authored but was motivated by a suggestion of AI.
2. If at any point you used AI's work in your contribution you must demonstrate that you can submit this under the license of the repository.
3. The accountability of using AI in a contribution lies by 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'.
7. Upon violation of the aforementioned agreements it is up to the discretion of the moderation team to handle it like a violation of Forgejo's COC.

Rationale

For each agreement I will explain the reason behind it and its intent, this is merely to help the reader understand what the agreements mean and their importance in this proposal. If the agreement is not clear or does not cover a use case, the agreement should be restated and not the rationale, because the proposed agreements are what Forgejo will agree to and not the reasoning I describe here.

Transparency

There are several benefits that transparency gives the Forgejo community about the usage of AI brings: expectations, bookkeeping and context.

When content is marked as being generated by AI it allows for other people to make the decision if they want to engage with AI generated content⁵ , it also sets the expectation that the content might contain deficiencies that is commonly seen in AI generated output⁶ .

In the interest of amendments to this proposal, having transparency about how and where AI is being used in Forgejo would allow for informed decision-making about the usage of AI without having to rely on second-hand sources and anecdotes from other projects. For users of Forgejo it also shows, if they put in some effort, how much and in what way AI is being used for development in Forgejo, which would allow them to make an informed decision if they want to use Forgejo or not.

If the contribution was made based on a suggestion from AI, including that suggestion will allow Forgejo reviewers to better understand why the change was made and if the suggestion is correct or necessary⁷ .

Licensing

First most, this is technically agreeing to enforcing Forgejo's DCO. However, in the context of AI this is of special interest to re-enforce this agreement by letting the authors demonstrate that AI's work can be submitted under the DCO.

Forgejo is not unknown to its licensing as seen from changing Forgejo's license from MIT to GPLv3; from this I derive that Forgejo contributors value their work being freely available under a copyleft license.

The licensing situation with AI is not clear, the training of the vast majority of AI models the datasets is not available and have been very likely trained with copyrighted material⁸ . That raises the question of how the output of AI is copyrighted and if it can be submitted under one license and under which author, this question has seen work by governments and copyright offices⁹ which to my knowledge only the academic community has responded to so far¹⁰ .

I do not believe that work of current AI, that is powerful enough and would be used by a (potential) Forgejo contributor, is capable of being licensed under FOSS license with a generic copyright author. Therefore, if a contribution uses AI's work, it has to be demonstrated that it can be licensed under the project's license. I do not want to risk copyright issues over allowing work from AI.

Accountability

I realize that this reads like a no-brainer (so obvious that it does not actually need to be expressed), however to avoid a philosophical/legal discussion if AI (or the provider of it) can be held accountable for its output I want to have the one submitting¹¹ AI's work to be responsible and accountable for its output; as if they wrote it themselves.

This is no different from when I submit a new tool for use within Forgejo, I am responsible and accountable for the accuracy and should fix any problems with it. And it is no different than I am responsible when I rely on rg to find all occurrences of a pattern and I gave a wrong pattern which then manifested in a bug because some code was not updated.

Communication

In general, a text generated largely by AI misses much of the intent and meaning of what the person using the AI wanted to convey. This can be seen in AI adding many sentences, citing non-relevant topics and giving their output in a generic format. Forgejo does not impose word requirements (like the education system would), and therefore I do not see the need for people to use AI when describing their work, problem or thoughts. If someone can write down what they mean in a few sentences, that's fine, and I'd prefer that to AI doing it for someone where much of the meaning would be lost. To put it this way, I think it is crucial for people to convey what they want to tell other people and don't let an AI decide this for them.

For code comments, if it is generated after the fact by AI it will merely describe the code itself and not what the author wanted to achieve with the code. In cases where people have to dig in the source code, either to find where a bug originated or why a particular behavior or mechanism was chosen to have code comments that the author written themselves (ideally before an implementation is written) is much more valuable to understand the code than achieving good code documentation because AI described the implementation.

Review comments can provide insight into how aspects of a feature or bug fix came about that are not otherwise revealed by reading the code. The discussion between a reviewer and the author shows how the PR was improved to solve a problem and thus also shows if previous implementations might not have solved the problem.¹² When you have to look at a PR that introduced a feature or fixed a bug years ago, it can help paint a picture of what the change is about, which can help determine why certain behaviors or why a certain mechanism was used and leads to making informed decisions if you want to improve or change it.¹³

Combining the previous two communication types, I conclude that the same must hold true for descriptions of pull requests. It is not so interesting to have AI describe the implementation (a Forgejo reviewer will have to read the code one way or another and will come hopefully to the same conclusion), advantages and disadvantages of the code and considerations to take into account; they do not replace why the author made the PR and what it wants to achieve with the change.

Issues are made with a purpose, someone faces a problem or a bug. I do not see the value of allowing AI to be involved in the process of describing what the person needs are or why some Forgejo behavior is incorrect. AI generated text might not follow the template that Forgejo provides, and it might leave out details that is otherwise crucial for a Forgejo contributor to resolve the issue. It's about solving a bug or a feature request for a person, and as such it feels like a natural requirement to have it being described by a person.

New content submitted to Forgejo documentation is currently written in a user-friendly tone that serves the target audience, I do not believe that the rather generic tone of AI is appropriate to see in documentation. Nor that AI is capable of understanding the target audience and, for example, able to give additional words to technical terms or explain common use cases that people will likely want to read about.

Code review

There are many general AI code review assistants¹⁴ that will happily review any PR that you throw at them. My personal experience with such AI is that they do not understand the context of the project and are quite short-sighted by highlighting issues that any other reviewer will not consider important: style issues, trying to be consistent with code from another project are and suggestions to solve made-up problems¹⁵ . In general, it does not know about blatantly wrong business logic in a code change, but it will write a lengthy essay about how you can solve the non-existent performance issue by reversing the arguments of a function.

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.

Autonomous

One of the recent features of code-based AI is to give the AI full control over code generation. This includes either with a human in the loop, vibe coding¹⁶ , where the human can be seen as a manager and giving a high-level overview of what the code needs to do and agent mode¹⁷ where AI is given a development environment and works as an autonomous agent to solve an issue that is given to them, optionally submit the change and addresses review comments.

I find both ways to be incompatible with the workflow of developing high-quality production-grade software. They result in the author not being an expert in the change they contribute, they are not aware of tradeoffs that were made or why a particular decision was taken and if all possible use-cases were considered; I question if they can address review comments without feeding them back to the same AI.¹⁸

Even if the same AI can be interrogated in the future to ask about its decision-making and thoughts and suggest bug fixes like you can do with a human Forgejo contributor, this is not possible with many current AI. They are often run in AI data centers and with continuous improvements in AI, a specific version/model of AI may no longer be available by the time someone wants to query it because the company behind the AI no longer offers it¹⁹ . There is AI that can be run locally, but it is often less powerful and not as tightly integrated as AI provided as a service by products that uses AI.

While this is already addressed in the accountability agreement, it is difficult and unrealistic to be accountable for AI's output if you are minimally involved in how that output was generated.

Enforcement

I do not want these agreements on AI to have any special status in terms of violations, which is why I want them to be considered a violation of the COC, so the moderation team does not have to treat them differently from other violations. The COC already has nice guidelines on how to deal with violations without immediately banning them after the first violation.

I also want to address the elephant in the room, you cannot enforce this without transparency, trust and honesty between Forgejo contributors. Someone can just say they did not use AI and there is no way for the moderation team to prove that they did use AI. I still think it is important to vote on the proposed agreements, it sends an important message about what Forgejo cares about and values; if there is no transparency and trust between participants then the use of AI is not the most important thing to address.

Remarks

I would like to highlight several points that are not addressed by this proposal:

1. Dependencies that Forgejo incorporates do not fall under these agreements and could, for example, have been made with the help of AI.
2. Other FOSS projects have put restrictions in place in disallowing AI generated security issues, this proposal does not impact that. As a member of the Forgejo Security team I have not seen this being a problem.
3. Using AI as a search engine is not forbidden as this does not directly translate into a contribution in Forgejo.
4. This does not reject implementing AI features in Forgejo. But if this proposal is agreed upon, I do not see that happening.

As I announced a week ago, hereby my proposal. As a reminder, all proposals that want to be considered for this discussion have to be submitted by next week 26 July in this issue. # Forgejo AI agreement proposal This is a proposal in response to [the discussion on the usage of AI in Forgejo](https://codeberg.org/forgejo/discussions/issues/366). This proposal seeks to heavily restrict the usage of AI in Forgejo in a pragmatic manner. ## Background ### Terminology The following explains terminology that is used in this proposal, but does not necessarily reflect the official or commonly used terminology. Software and services that heavily rely on large language model technology to generate their outcomes are referred to as Artificial Intelligence (AI). Examples of products that fit this definition: GitHub Copilot, ChatGPT, Claude Sonnet, DeepSeek, Llama and Gemini. There's a distinction between general and narrow AI, all the aforementioned examples fall under general AI as they were not trained to execute a specific well-defined task. Narrow AI is trained to be used for specific well-defined tasks where the problem space is known in advance, an example is given in the last paragraph in the [code review section](#code-review). ### Aim The aim of this proposal is to have a set of agreements that clarifies and give guidance for the usage of AI in any repository that falls under Forgejo's governance[^1]. Specifically it seeks to maximize the following five points: 1. It should be clear to any contributor in what way AI can and cannot be used in their contribution to Forgejo. 2. It should be clear to any contributor what their responsibility is when they choose to use AI for their contribution to Forgejo. 3. It should be clear to any reviewer of the code in what way and to which significance AI was used in the creation of a code change and communication. 4. It should be clear to people (considering) using Forgejo how AI is used in Forgejo's development. 5. There's clear guidance on how to deal with violations of the proposed agreements in this proposal. [^1]: A non-exhaustive list at the time of writing this proposal: repositories in https://codeberg.org/forgejo, https://code.forgejo.org/forgejo and https://code.forgejo.org/go-chi and https://code.forgejo.org/forgejo-helm. ### Current situation Within the FOSS community, policies have been adopt that ban AI over concerns of quality, licensing and ecological reasons.[^2] [^2]: Another non-exhaustive list: [curl](https://curl.se/dev/contribute.html#on-ai-use-in-curl), [QEMU](https://github.com/qemu/qemu/blob/master/docs/devel/code-provenance.rst#use-of-ai-content-generators), [Servo](https://book.servo.org/contributing.html#ai-contributions), [Loupe](https://gitlab.gnome.org/GNOME/loupe/-/blob/main/CONTRIBUTING.md?ref_type=heads#use-of-generative-ai), [Gentoo Linux](https://wiki.gentoo.org/wiki/Project:Council/AI_policy) People have chosen Forgejo over other forges as it is not being invested with AI features[^3] and I strongly believe they would dislike seeing AI being used for Forgejo's development. [^3]: Forgejo and Codeberg has been numerous times mentioned each time GitHub pushed yet another AI feature into developers faces, the latest being https://github.com/orgs/community/discussions/159749. FOSS projects that have accepted the use of AI contributions (or integrated AI features) have not been received well within the FOSS community; going on the record that you allow AI does not reflect well on the project.[^4] [^4]: Recent examples include [Servo allowing AI contributions](https://floss.social/@servo/114296977894869359) and [Gitea announcing Gitea MCP server](https://social.gitea.io/@gitea/114275472231870857). ## Agreement Before explaining the rationale behind the agreements, these are the exact agreements I propose: 1. If content was made with the help of AI, you must convey that this is the case. This includes content that you authored but was motivated by a suggestion of AI. 2. If at any point you used AI's work in your contribution you must demonstrate that you can submit this under the license of the repository. 3. The accountability of using AI in a contribution lies by 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'. 7. Upon violation of the aforementioned agreements it is up to the discretion of the moderation team to handle it like a violation of [Forgejo's COC](https://codeberg.org/forgejo/code-of-conduct). ## Rationale For each agreement I will explain the reason behind it and its intent, this is merely to help the reader understand what the agreements mean and their importance in this proposal. If the agreement is not clear or does not cover a use case, the agreement should be restated and not the rationale, because the proposed agreements are what Forgejo will agree to and not the reasoning I describe here. ### Transparency There are several benefits that transparency gives the Forgejo community about the usage of AI brings: expectations, bookkeeping and context. When content is marked as being generated by AI it allows for other people to make the decision if they want to engage with AI generated content[^20], it also sets the expectation that the content might contain deficiencies that is commonly seen in AI generated output[^12]. [^12]: [ChatGPT is bullshit](https://link.springer.com/article/10.1007/s10676-024-09775-5) and [Package Hallucinations: How LLMs Can Invent Vulnerabilities](https://www.usenix.org/publications/loginonline/we-have-package-you-comprehensive-analysis-package-hallucinations-code) [^20]: For example for people that are concerned about the ecological impact of AI: [AI's Energy and Water Implications](https://aienergywater.netlify.app/). In the interest of amendments to this proposal, having transparency about how and where AI is being used in Forgejo would allow for informed decision-making about the usage of AI without having to rely on second-hand sources and anecdotes from other projects. For users of Forgejo it also shows, if they put in some effort, how much and in what way AI is being used for development in Forgejo, which would allow them to make an informed decision if they want to use Forgejo or not. If the contribution was made based on a suggestion from AI, including that suggestion will allow Forgejo reviewers to better understand why the change was made and if the suggestion is correct or necessary[^16]. [^16]: This is to avoid falling into the [XY problem](https://meta.stackexchange.com/a/66378), where AI might believe there's a problem and suggest a solution for it. ### Licensing First most, this is technically agreeing to enforcing [Forgejo's DCO](https://forgejo.org/docs/next/contributor/dco/). However, in the context of AI this is of special interest to re-enforce this agreement by letting the authors demonstrate that AI's work can be submitted under the DCO. Forgejo is not unknown to its licensing as seen from changing [Forgejo's license from MIT to GPLv3](https://forgejo.org/2024-08-gpl/); from this I derive that Forgejo contributors value their work being freely available under a copyleft license. The licensing situation with AI is not clear, the training of the vast majority of AI models the datasets is not available and have been *very likely* trained with copyrighted material[^5]. That raises the question of how the output of AI is copyrighted and if it can be submitted under one license and under which author, this question has seen work by governments and copyright offices[^6] which to my knowledge only the academic community has responded to so far[^8]. [^5]: ["OpenAI says it’s "impossible" to create useful AI models without copyrighted material"](https://arstechnica.com/information-technology/2024/01/openai-says-its-impossible-to-create-useful-ai-models-without-copyrighted-material) by Ars Technica. Many **ongoing** lawsuits have alleged this such, most relevantly [GitHub Copilot litigation](https://githubcopilotlitigation.com). [^6]: [EU's AI Act](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) and [Generative Artificial Intelligence and Copyright Law](https://www.congress.gov/crs-product/LSB10922) an American legal sidebar. [^8]: ["A language model built for the public good"](https://ethz.ch/en/news-and-events/eth-news/news/2025/07/a-language-model-built-for-the-public-good.html) by ETH Zurich. I do not believe that work of current AI, that is powerful enough and would be used by a (potential) Forgejo contributor, is capable of being licensed under FOSS license with a generic copyright author. Therefore, if a contribution uses AI's work, it has to be demonstrated that it can be licensed under the project's license. I do not want to risk copyright issues over allowing work from AI. ### Accountability I realize that this reads like a no-brainer (so obvious that it does not actually need to be expressed), however to avoid a philosophical/legal discussion if AI (or the provider of it) can be held accountable for its output I want to have the one submitting[^9] AI's work to be responsible and accountable for its output; as if they wrote it themselves. [^9]: I could have said "using AI work", however a troll could apply a "Clean-room design" technique where one person uses AI and the other person submits the AI's work - by clarifying it is the one submitting we hold the one bringing AI's work to Forgejo accountable. This is no different from when I submit [a new tool](https://codeberg.org/forgejo/forgejo/pulls/5703) for use within Forgejo, I am responsible and accountable for the accuracy and should fix any problems with it. And it is no different than I am responsible when I rely on [`rg`](https://github.com/BurntSushi/ripgrep/) to find all occurrences of a pattern and I gave a wrong pattern which then manifested in a bug because some code was not updated. ### Communication In general, a text generated largely by AI misses much of the intent and meaning of what the person using the AI wanted to convey. This can be seen in AI adding many sentences, citing non-relevant topics and giving their output in a generic format. Forgejo does not impose word requirements (like the education system would), and therefore I do not see the need for people to use AI when describing their work, problem or thoughts. If someone can write down what they mean in a few sentences, that's fine, and I'd prefer that to AI doing it for someone where much of the meaning would be lost. To put it this way, I think it is crucial for people to convey what they want to tell other people and don't let an AI decide this for them. For code comments, if it is generated after the fact by AI it will merely describe the code itself and not what the author wanted to achieve with the code. In cases where people have to dig in the source code, either to find where a bug originated or why a particular behavior or mechanism was chosen to have code comments that the author written themselves (ideally before an implementation is written) is much more valuable to understand the code than achieving good code documentation because AI described the implementation. Review comments can provide insight into how aspects of a feature or bug fix came about that are not otherwise revealed by reading the code. The discussion between a reviewer and the author shows how the PR was improved to solve a problem and thus also shows if previous implementations might not have solved the problem.[^10] When you have to look at a PR that introduced a feature or fixed a bug years ago, it can help paint a picture of what the change is about, which can help determine why certain behaviors or why a certain mechanism was used and leads to making informed decisions if you want to improve or change it.[^11] [^10]: A recent example that show this: https://codeberg.org/forgejo/forgejo/pulls/8451#issuecomment-5765825. [^11]: Another example, for much code from Gogs that is still present in the Forgejo codebase it is not possible to infer why it was introduced or what its intent is (this is usually caused by multiple features and bug fixes being introduced via 1 commit). If this ends up being a security issue, causing bugs, or you need to change the way it is implemented, then you have to spend a lot more time getting a picture of what the code actually does and how it handles all the existing cases. Combining the previous two communication types, I conclude that the same must hold true for descriptions of pull requests. It is not so interesting to have AI describe the implementation (a Forgejo reviewer will have to read the code one way or another and will come _hopefully_ to the same conclusion), advantages and disadvantages of the code and considerations to take into account; they do not replace why the author made the PR and what it wants to achieve with the change. Issues are made with a purpose, someone faces a problem or a bug. I do not see the value of allowing AI to be involved in the process of describing what the person needs are or why some Forgejo behavior is incorrect. AI generated text might not follow the template that Forgejo provides, and it might leave out details that is otherwise crucial for a Forgejo contributor to resolve the issue. It's about solving a bug or a feature request for a person, and as such it feels like a natural requirement to have it being described by a person. New content submitted to Forgejo documentation is currently written in a user-friendly tone that serves the target audience, I do not believe that the rather generic tone of AI is appropriate to see in documentation. Nor that AI is capable of understanding the target audience and, for example, able to give additional words to technical terms or explain common use cases that people will likely want to read about. ### Code review There are many general AI code review assistants[^7] that will happily review any PR that you throw at them. My personal experience with such AI is that they do not understand the context of the project and are quite short-sighted by highlighting issues that any other reviewer will not consider important: style issues, trying to be consistent with code from another project are and suggestions to solve made-up problems[^19]. In general, it does not know about blatantly wrong [business logic](https://en.wikipedia.org/wiki/Business_logic) in a code change, but it will write a lengthy essay about how you can solve the non-existent performance issue by reversing the arguments of a function. [^7]: Non-exhaustive list: [GitHub Copilot code review](https://docs.github.com/en/copilot/how-tos/agents/copilot-code-review/using-copilot-code-review), [CodeRabbit](https://www.coderabbit.ai/). [^19]: One could argue that this is a form of [bikeshedding](https://bikeshed.com/). 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. ### Autonomous One of the recent features of code-based AI is to give the AI full control over code generation. This includes either with a human in the loop, vibe coding[^14], where the human can be seen as a manager and giving a high-level overview of what the code needs to do and agent mode[^13] where AI is given a development environment and works as an autonomous agent to solve an issue that is given to them, optionally submit the change and addresses review comments. [^14]: I am not able to find any good (peer-reviewed) scientific or journalistic articles that give an overview of vibe coding so [the Wikipedia page](https://en.wikipedia.org/wiki/Vibe_coding) should have to do it for now. [^13]: Non-exhaustive list of currently available AI that offers an agent mode: [GitHub's Copilot coding agent](https://docs.github.com/en/copilot/concepts/about-copilot-coding-agent), [VS Code's agent mode](https://code.visualstudio.com/blogs/2025/04/07/agentMode) and [Augment Code](https://www.augmentcode.com). I find both ways to be incompatible with the workflow of developing high-quality production-grade software. They result in the author not being an expert in the change they contribute, they are not aware of tradeoffs that were made or why a particular decision was taken and if all possible use-cases were considered; I question if they can address review comments without feeding them back to the same AI.[^15] [^15]: When giving feedback to AI, they rarely apply critical thinking and instead opt to give in to the feedback, even if the feedback is wrong, does not make sense or is a suggestion for another tradeoff. Even if the same AI can be interrogated in the future to ask about its decision-making and thoughts and suggest bug fixes like you can do with a human Forgejo contributor, this is not possible with many current AI. They are often run in AI data centers and with continuous improvements in AI, a specific version/model of AI may no longer be available by the time someone wants to query it because the company behind the AI no longer offers it[^17]. There is AI that can be run locally, but it is often less powerful and not as tightly integrated as AI provided as a service by products that uses AI. [^17]: Assuming the AI would still have the context and history of when it generated the output and the conversation it had with the person who asked the AI to generate that output, otherwise you would be asking a stranger to do ask about someone else's rationale. While this is already addressed in the accountability agreement, it is difficult and unrealistic to be accountable for AI's output if you are minimally involved in how that output was generated. ### Enforcement I do not want these agreements on AI to have any special status in terms of violations, which is why I want them to be considered a violation of the COC, so the moderation team does not have to treat them differently from other violations. The COC already has nice guidelines on how to deal with violations without immediately banning them after the first violation. I also want to address the elephant in the room, you cannot enforce this without transparency, trust and honesty between Forgejo contributors. Someone can just say they did not use AI and there is no way for the moderation team to prove that they did use AI. I still think it is important to vote on the proposed agreements, it sends an important message about what Forgejo cares about and values; if there is no transparency and trust between participants then the use of AI is not the most important thing to address. ## Remarks I would like to highlight several points that are not addressed by this proposal: 1. Dependencies that Forgejo incorporates do not fall under these agreements and could, for example, have been made with the help of AI. 2. Other FOSS projects have put restrictions in place in disallowing AI generated security issues, this proposal does not impact that. As a member of the Forgejo Security team I have not seen this being a problem. 3. Using AI as a search engine is not forbidden as this does not directly translate into a contribution in Forgejo. 4. This does not reject implementing AI features in Forgejo. But if this proposal is agreed upon, I do not see that happening.

fogti commented 2025年07月20日 12:51:51 +02:00

I think it would be a good idea to state that "LLM" stands for "large language model". It might make sense to make the terminology section a bit more in-depth, or link to some definition (as already done e.g. for "vibe coding" and "agent mode"), to make sure that the definitions don't drift unintentionally over time, or include some revision mechanism in case that what we count as "AI" needs to be broadened due to newer, unforeseen developments.

Otherwise, I think the proposal is really good.

I think it would be a good idea to state that "LLM" stands for "large language model". It might make sense to make the terminology section a bit more in-depth, or link to some definition (as already done e.g. for "vibe coding" and "agent mode"), to make sure that the definitions don't drift unintentionally over time, or include some revision mechanism in case that what we count as "AI" needs to be broadened due to newer, unforeseen developments. Otherwise, I think the proposal is really good.

n0toose commented 2025年07月20日 14:33:28 +02:00

I think @Gusted's proposal directly and eloquently raises concerns on how such current technologies in their current form (today) can heavily impact Forgejo's long-term sustainability, standing in the free software community (spot on with the Gitea example where people said "just use Forgejo instead") and raise questions involving copyright and relying on "silos". It combines ideological (unanswered) questions and lived experiences, although I'd also appreciate more clarity on definitions.

Some further thoughts that I don't want to clutter the thread with.

Many such points were mentioned briefly already (including output quality), yet not many directly engaged with the points or asked for an elaboration – @gusted's post builds on top of them. IMHO only @earl-warren's post got close, and argued (IIRC) that this can alienate contributors: Sorry, but I am constantly reminded that the project is bigger than individuals – we should not alienate future contributors or harm our hard-earned perceived seriousness after being initially known as "yet another rage fork" (e.g. even GCC is experimenting with Forgejo now).

We collectively earned that because of our focus on sustainability, including, but not limited to, Earl's and gusted's very hard work. Such a policy would be part of a series of proposals that "hinder progress" (namely focusing on bug fixes than skillsets - so as to learn to work with people and have them learn) in the name of sustainability over the "move fast and break things" approach. Some might not be used to this, but everyone who can, does adjust. This project is bigger than skillsets and "geniuses"; this gives me room to learn from (repeated) mistakes and improve.

All these points is what makes Forgejo wonderful in the face of an increasingly "enshittified", "siloed", non-human-centric Internet. It is produced by humans for humans, and encourages them to create and share. I would not like that to change. If our processes are not good for humans to follow, we should listen to such concerns and work towards refining them (e.g. provide boilerplate code and tutorials on writing tests - which is a problem).

I think @Gusted's proposal directly and eloquently raises concerns on how such current technologies in their current form (today) can heavily impact Forgejo's long-term sustainability, standing in the free software community (spot on with the Gitea example where people said "just use Forgejo instead") and raise questions involving copyright and relying on "silos". It combines ideological (unanswered) questions and lived experiences, although I'd also appreciate more clarity on definitions. <details> <summary>Some further thoughts that I don't want to clutter the thread with.</summary> Many such points were mentioned briefly already (including output quality), yet not many directly engaged with the points or asked for an elaboration – @gusted's post builds on top of them. IMHO only @earl-warren's post got close, and argued (IIRC) that this can alienate contributors: Sorry, but I am constantly reminded that the project is bigger than individuals – we should not alienate future contributors or harm our hard-earned perceived seriousness after being initially known as "yet another rage fork" (e.g. even GCC is experimenting with Forgejo now). We collectively earned that because of our focus on sustainability, including, but not limited to, Earl's and gusted's very hard work. Such a policy would be part of a series of proposals that "hinder progress" (namely focusing on bug fixes than skillsets - so as to learn to work with people and have them learn) in the name of sustainability over the "move fast and break things" approach. Some might not be used to this, but everyone who can, does adjust. This project is bigger than skillsets and "geniuses"; this gives me room to learn from (repeated) mistakes and improve. All these points is what makes Forgejo wonderful in the face of an increasingly "enshittified", "siloed", non-human-centric Internet. It is produced by humans for humans, and encourages them to create and share. I would not like that to change. If our processes are not good for humans to follow, we should listen to such concerns and work towards refining them (e.g. provide boilerplate code and tutorials on writing tests - which *is* a problem). </details>

earl-warren commented 2025年07月20日 16:59:08 +02:00

Proposal

The following is added to the Code of Conduct.

modified README.md
@@ -32,6 +32,8 @@ community include:
 
 Examples of unacceptable behavior include:
 
+* Publishing AI generated content (code or text) that the author is unable to write without
+ the help of an AI.
 * The use of sexualized language or imagery, and sexual attention or advances of
 any kind
 * Trolling, insulting or derogatory comments, and personal or political attacks

Rationale

The Forgejo community is based on trust. Every new contributor is trusted by default and it is the responsibility of the moderation team to gently remind newcomers that some behaviors are not acceptable.

AI generated content published by contributors who are not able to create that same content on their own is problematic. It deserves to be pointed as a behavior that is not tolerated, because:

• It takes a long time to read for other people only to realize it is not human written for the most part
• It produces code, comments or reviews that the contributor cannot fix because they do not understand them

By adding this abusive use of AI to the list of unacceptable behavior, the moderation team will be in a position to legitimately and kindly:

• Ask someone about the extend of their use of AI
• Ask them to stop using AI and demonstrate they can do without, at least for some time

Example

A feature request was originally written with the help of an AI. When asked about it the author admitted to it and was willing to rewrite it. Such a request could be made by the moderation team, maybe using a template so the new contributor does not feel bad about this honest mistake and be more inclined to do the right thing going forward.

## Proposal The following is added to the [Code of Conduct](https://codeberg.org/forgejo/code-of-conduct/src/commit/c4e1d428922ecf1f4e3b8e193fe4ee2ca471fa79/README.md). ```diff modified README.md @@ -32,6 +32,8 @@ community include: Examples of unacceptable behavior include: +* Publishing AI generated content (code or text) that the author is unable to write without + the help of an AI. * The use of sexualized language or imagery, and sexual attention or advances of any kind * Trolling, insulting or derogatory comments, and personal or political attacks ``` ## Rationale The Forgejo community is based on trust. Every new contributor is trusted by default and it is the responsibility of the moderation team to gently remind newcomers that some behaviors are not acceptable. AI generated content published by contributors who are not able to create that same content on their own is problematic. It deserves to be pointed as a behavior that is not tolerated, because: - It takes a long time to read for other people only to realize it is not human written for the most part - It produces code, comments or reviews that the contributor cannot fix because they do not understand them By adding this abusive use of AI to the list of unacceptable behavior, the moderation team will be in a position to legitimately and kindly: - Ask someone about the extend of their use of AI - Ask them to stop using AI and demonstrate they can do without, at least for some time ## Example A [feature request](https://codeberg.org/forgejo/forgejo/issues/8566) was originally written with the help of an AI. When asked about it the author admitted to it and was willing to rewrite it. Such a request could be made by the moderation team, maybe using a template so the new contributor does not feel bad about this honest mistake and be more inclined to do the right thing going forward.

earl-warren commented 2025年07月20日 17:01:33 +02:00

@Gusted I find your comment very well written and I stand behind everything (modulo some points on licensing but that's a detail). I think it would make for a fine statement to be published on the Forgejo blog.

@Gusted I find your comment very well written and I stand behind everything (modulo some points on licensing but that's a detail). I think it would make for a fine statement to be published on the Forgejo blog.

Gusted commented 2025年07月27日 22:40:39 +02:00

Hi everyone,

It has been two weeks since I asked everyone to submit proposals to conclude this discussion. Four proposals have been submitted.

The proposals are unique but also have some overlap, therefore I see the following seven outcomes:

1. Otto's transparency proposal is agreed upon. (👍)
2. Otto's consent proposal is agreed upon. (👎)
3. Otto's transparency and consent proposal is agreed upon. (😆)
4. Gusted's proposal is agreed upon. (🎉)
5. Gusted's proposal using Earl Warren's Code of Conduct proposal is agreed upon. (😕)
6. Gusted's proposal using Earl Warren's Code of Conduct proposal is agreed upon and published. (❤️)
7. Earl Warren's Code of Conduct proposal is agreed upon. (🚀)

I would like to ask everyone to say with which outcome you are willing to live with and are comfortable with, you do this by giving a emoji to this comment. You are allowed to react with multiple emojis.

If you have any concerns about a particular outcome, I encourage you to state what your concern is and what is important to you that prevents you from feeling comfortable with the outcome. That feedback will be used in case that outcome receives the least opposition¹ .

The decision-making guidelines recommend two weeks before going to step 7. I think this is enough time, and as such I continue with this step on 10 August.

If you have any questions or disagreements with this, please state so here or privately to me and I will try my best to address them.

Hi everyone, It has been two weeks since I asked everyone to submit proposals to conclude this discussion. Four proposals have been submitted. The proposals are unique but also have some overlap, therefore I see the following seven outcomes: 1. [Otto's transparency proposal](https://codeberg.org/forgejo/discussions/issues/366#issuecomment-5811095) is agreed upon. (:+1:) 2. [Otto's consent proposal](https://codeberg.org/forgejo/discussions/issues/366#issuecomment-5811095) is agreed upon. (:-1:) 3. [Otto's transparency and consent proposal](https://codeberg.org/forgejo/discussions/issues/366#issuecomment-5811095) is agreed upon. (:laugh:) 4. [Gusted's proposal](https://codeberg.org/forgejo/discussions/issues/366#issuecomment-5897575) is agreed upon. (:hooray:) 5. [Gusted's proposal](https://codeberg.org/forgejo/discussions/issues/366#issuecomment-5897575) using [Earl Warren's Code of Conduct proposal](https://codeberg.org/forgejo/discussions/issues/366#issuecomment-5904460) is agreed upon. (:confused:) 6. [Gusted's proposal](https://codeberg.org/forgejo/discussions/issues/366#issuecomment-5897575) using [Earl Warren's Code of Conduct proposal](https://codeberg.org/forgejo/discussions/issues/366#issuecomment-5904460) is agreed upon and published. (:heart:) 7. [Earl Warren's Code of Conduct proposal](https://codeberg.org/forgejo/discussions/issues/366#issuecomment-5904460) is agreed upon. (:rocket:) **I would like to ask everyone to say with which outcome you are willing to live with and are comfortable with, you do this by giving a emoji to this comment. You are allowed to react with multiple emojis.** If you have any concerns about a particular outcome, I encourage you to state what your concern is and what is important to you that prevents you from feeling comfortable with the outcome. That feedback will be used in case that outcome receives the least opposition[^1]. [^1]: The outcome that receives the most emojis. The decision-making guidelines recommend two weeks before going to step 7. I think this is enough time, and as such I continue with this step on **10 August**. If you have any questions or disagreements with this, please state so here or privately to me and I will try my best to address them.

Gusted commented 2025年07月27日 22:45:33 +02:00

If my proposal ends up being accepted in some way I would like to address the feedback by making the terminology section more in-depth. I believe that this does not have a significant impact on the proposal and it is merely intended to clarify what the definitions mean today.

Context: #366 (comment)

If my proposal ends up being accepted in some way I would like to address the feedback by making the terminology section more in-depth. I believe that this does not have a significant impact on the proposal and it is merely intended to clarify what the definitions mean today. Context: https://codeberg.org/forgejo/discussions/issues/366#issuecomment-5901964

viceice commented 2025年07月28日 11:52:01 +02:00

@Gusted can you link to the proposal comments. so they're easier to find?

@Gusted can you link to the proposal comments. so they're easier to find?

Beowulf commented 2025年07月29日 19:08:48 +02:00

What is meant with and published (difference between 5. and 6.)?

What is meant with `and published` (difference between 5. and 6.)?

Gusted commented 2025年07月29日 20:31:34 +02:00

I should have elaborated that, it's a reference to the last paragraph of #366 (comment). The proposal could be retrofitted as a statement of why Forgejo choose for this agreement.

I should have elaborated that, it's a reference to the last paragraph of https://codeberg.org/forgejo/discussions/issues/366#issuecomment-5904469. The proposal could be retrofitted as a statement of why Forgejo choose for this agreement.

mahlzahn commented 2025年08月02日 01:00:51 +02:00

It’s not really for choice, but in case of @Gusted’s proposal being accepted, I think that it makes a great draft of a website post announcing the Forgejo’s direction in that matter (choice 6. without Earl’s proposal, but with publication). But that’s the next step ...

It’s not really for choice, but in case of @Gusted’s proposal being accepted, I think that it makes a great draft of a website post announcing the Forgejo’s direction in that matter (choice 6. without Earl’s proposal, but with publication). But that’s the next step ...

Gusted commented 2025年08月02日 01:02:48 +02:00

Sorry, I should've included that option. But yeah that can still be done if option 4 is accepted.

Sorry, I should've included that option. But yeah that can still be done if option 4 is accepted.

waldyrious commented 2025年08月05日 16:12:28 +02:00

I'm confused at the option to vote for Otto's transparency, consent, and transparency+consent proposals separately, when one can vote for multiple options. Doesn't 👍 and 👎 equate to 😆?

Also, it's unclear from the links what those options refer to. Do they refer only to the following text?

Transparency: We need to evaluate the usage of "AI" in Forgejo and learn more about the effects.
Consent: Contributors in Forgejo need a way to decide not to deal with AI content (e.g. refusing reviews or triaging issues when AI was involved).

...or are we to consider the whole comment text as the final wording? And why are options 1, 2 and 3 all pointing to the same comment? Is that intentional? what about Otto's next two comments?

In a related note, I'm also confused as to what Gusted's proposal entails. Is it the entirety of their comment, with that specific wording? If so, I worry that it may be rather verbose and lead to a ToS-like situation where people won't really read and understand fully those terms, whereas Otto's phrasing (even considering the entirety of their comment) seems considerably more readable, IMHO.

I'm confused at the option to vote for Otto's transparency, consent, and transparency+consent proposals separately, when one can vote for multiple options. Doesn't 👍 and 👎 equate to 😆? Also, it's unclear from the links what those options refer to. Do they refer only to the following text? > Transparency: We need to evaluate the usage of "AI" in Forgejo and learn more about the effects. > Consent: Contributors in Forgejo need a way to decide not to deal with AI content (e.g. refusing reviews or triaging issues when AI was involved). ...or are we to consider the whole comment text as the final wording? And why are options 1, 2 and 3 all pointing to the same comment? Is that intentional? what about Otto's next two comments? In a related note, I'm also confused as to what Gusted's proposal entails. Is it the entirety of their comment, with that specific wording? If so, I worry that it may be rather verbose and lead to a ToS-like situation where people won't really read and understand fully those terms, whereas Otto's phrasing (even considering the entirety of their comment) seems considerably more readable, IMHO.

pat-s commented 2025年08月05日 17:10:31 +02:00

tl;dr: add some practical rules which state something along the lines: "no AI-based PR descriptions, (ideally) no AI-based tests, ideally nothing from AI, but we are aware (and not naive), we can't spot all of it".
Add these to PR and issue templates and avoid a wall of text which is mainly a long moral wishlist but doesn't enforce clear practical rules that can be asserted.

---

I see and understand the motivation to find a good written phrasing for what most people in the community seem to want, however, I think that all of the current proposals are not adhering to practical reality.

AI is much like Stackoverflow back in the days: back then, people got upset if they found code c/p from SO. If that was even detected. It was about moral, honor and nobody could verify that person X really has the skills for the code it c/p.
Meanwhile, this is accepted, not only but also there is a new enemy in town.

The use of AI is quite similar. Most arguments here circle around the fact of "we want devs to understand all code and only contribute it, if they can solely write it themselves". There is no way anyone can ever proof this.
While the general take is honorable, it is also somewhat naive and neglects reality, because there is no way to verify the skills of contributor X in relation to their contribution.
In many ways however, there is no difference between AI and c/p a code snippet from SO when breaking it down to the practical relevance. In the end, a large part of the training data comes from (commented) code snippets on SO.
Hence, I am quite skeptical about the addition of too much text that is mostly on the meta-side and can't be enforced.
Devs know that if something should be enforced, there must be a way to clearly detect if something is valid/allowed or not.

The only AI artifact one can (somewhat) easily detect and push back are common code/text patterns by AI, e.g. PR descriptions and (too) verbose code comments. (At least now, as models might become better so that they understand when they sound like an AI and prevent that from happening.)
However, at some point, people will just tell AI to "add some variance, include some errors in the text and make it sound more human" to circumvent this.
There's no reality in which this won't happen to FJ-related repos.

In addition, the more FJ states which AI patterns it doesn't want, the more people will start to work-around these, aiming to hide them while still getting the content in they want to have merged. This paired with the fact that people can't state they have used AI (as they would be stigmatized then), they are motivated to hide this fact and do everything to let it look like non-AI code.
And exactly here we're back at the beginning: as there is no way to verify what people do locally and only the result (=code) counts, I do think its not helpful to have such strict moral rules while missing out on the practical enforcements that would be possible.

And to everyone arriving here and aiming to downvote this (while on the go): please add a written reply instead and argue using words, not emojis.

tl;dr: add some practical rules which state something along the lines: "no AI-based PR descriptions, (ideally) no AI-based tests, ideally nothing from AI, but we are aware (and not naive), we can't spot all of it". Add these to PR and issue templates and avoid a wall of text which is mainly a long moral wishlist but doesn't enforce clear practical rules that can be asserted. --- I see and understand the motivation to find a good written phrasing for what most people in the community seem to want, however, I think that all of the current proposals are not adhering to practical reality. AI is much like Stackoverflow back in the days: back then, people got upset if they found code c/p from SO. *If* that was even detected. It was about moral, honor and nobody could verify that person X really has the skills for the code it c/p. Meanwhile, this is accepted, not only but also there is a new enemy in town. The use of AI is quite similar. Most arguments here circle around the fact of "we want devs to understand all code and only contribute it, if they can solely write it themselves". *There is no way anyone can ever proof this.* While the general take is honorable, it is also somewhat naive and neglects reality, because there is no way to verify the skills of contributor X in relation to their contribution. In many ways however, there is no difference between AI and c/p a code snippet from SO when breaking it down to the practical relevance. In the end, a large part of the training data comes from (commented) code snippets on SO. Hence, I am quite skeptical about the addition of too much text that is mostly on the meta-side and can't be enforced. Devs know that if something should be enforced, there must be a way to clearly detect if something is valid/allowed or not. The *only* AI artifact one can (somewhat) easily detect and push back are common code/text patterns by AI, e.g. PR descriptions and (too) verbose code comments. (At least now, as models might become better so that they understand when they sound like an AI and prevent that from happening.) However, at some point, people will just tell AI to "add some variance, include some errors in the text and make it sound more human" to circumvent this. There's no reality in which this won't happen to FJ-related repos. In addition, the more FJ states which AI patterns it doesn't want, the more people will start to work-around these, aiming to hide them while still getting the content in they want to have merged. This paired with the fact that people can't state they have used AI (as they would be stigmatized then), they are motivated to hide this fact and do everything to let it look like non-AI code. And exactly here we're back at the beginning: as there is no way to verify what people do locally and only the result (=code) counts, I do think its not helpful to have such strict moral rules while missing out on the practical enforcements that would be possible. And to everyone arriving here and aiming to downvote this (while on the go): please add a written reply instead and argue using words, not emojis.

fnetX commented 2025年08月05日 20:12:15 +02:00

And to everyone arriving here and aiming to downvote this (while on the go): please add a written reply instead and argue using words, not emojis.

I don't think this is a reasonable request. In my eyes, it is very legitimate to share general sentiment towards a comment and collect a cut of the opinions without turning it all into words first. And I like to know if peoplenfeel the same without parsing a wall of follow-up comments (which might be in weird order) first. Maybe both tasks are easy to do with AI 🤷

> And to everyone arriving here and aiming to downvote this (while on the go): please add a written reply instead and argue using words, not emojis. I don't think this is a reasonable request. In my eyes, it is very legitimate to share general sentiment towards a comment and collect a cut of the opinions without turning it all into words first. And I like to know if peoplenfeel the same without parsing a wall of follow-up comments (which might be in weird order) first. Maybe both tasks are easy to do with AI 🤷

earl-warren commented 2025年08月10日 18:39:33 +02:00

https://xkcd.com/3126/ was mentioned by @infinoid when I asked if they authored a long comment before starting to read it. Very relevant. And kind of funny 😁

image

https://xkcd.com/3126/ was mentioned by @infinoid when I asked [if they authored a long comment before starting to read it](https://codeberg.org/forgejo/discussions/issues/66#issuecomment-6206995). Very relevant. And kind of funny 😁 

KaKi87 commented 2025年08月30日 00:15:06 +02:00

Hi,

Sorry I'm a little late to the party and have a few questions.

On the use of AI autocomplete

I use LLMs all the time to write code – however, not in the form of "vibe coding" [...] but almost exclusively in the form of inline suggestions [...] By banning AI entirely, such inline auto-complete suggestions would be banned too, which I'd find detrimental.

Did anyone actually answer this ?

As I have the same experience as @pixelcode, I share their opinion and would like some feedback about it.

It is also not mentioned at all in the text at forgejo/governance#325.

On the use of AI for issues and comments

The abovementioned text also says :

issues [...] and comments on issues [...] intended to be read by people to understand your thoughts and work must not have been generated with AI

Does that apply :

• only to Forgejo team members while carrying out their work as a team member ;
• or only to Forgejo team members whether carrying out their work a team member or participating outside of that perimeter ;
• or also to Forgejo contributors whether they are or aren't members of a Forgejo team ;
• or also to any Forgejo community member participating in any way ?

And in the last 2 cases, shouldn't the Code of Conduct also be updated to mention this new document, in order to be legitimately enforceable, given that the people involved aren't required to make a pledge ?

On my past use of AI for issues

Because of this discussion, I guess I should admit that I used Mistral AI to write the last two issues I submitted to the Forgejo repository (#8564 & #8741), which I'm sure no one noticed and no one was bothered by, as my only use for it was to feed it my feature request as a simple sentence and have it elaborate on that request in a way that follows the template, which work I double-checked and applied corrections before submitting.

Therefore, I also disagree on banning the use of AI for this purpose.

On my use of AI to write this comment

AI was not used at all to write this comment.

On Gitea's use of AI

Is there information on if and how Gitea uses AI ? This might impact the practice of cherry-picking from Gitea to Forgejo.

On the use of AI chat

In addition to auto-completion, I sometimes use AI the same way I would use StackOverflow : to get a small piece of code to get inspiration from to implement something, or to get an explanation on why an error occurs.

What about that ?

---

Thank you

Hi, Sorry I'm a little late to the party and have a few questions. ### On the use of AI autocomplete > I use LLMs all the time to write code – however, not in the form of "vibe coding" [...] but almost exclusively in the form of inline suggestions [...] By banning AI entirely, such inline auto-complete suggestions would be banned too, which I'd find detrimental. Did anyone actually answer this ? As I have the same experience as @pixelcode, I share their opinion and would like some feedback about it. It is also not mentioned at all in the [text at forgejo/governance#325](https://codeberg.org/forgejo/governance/pulls/325/files). ### On the use of AI for issues and comments The abovementioned text also says : > issues [...] and comments on issues [...] intended to be read by people to understand your thoughts and work must not have been generated with AI Does that apply : - only to Forgejo team members while carrying out their work as a team member ; - or only to Forgejo team members whether carrying out their work a team member or participating outside of that perimeter ; - or also to Forgejo contributors whether they are or aren't members of a Forgejo team ; - or also to any Forgejo community member participating in any way ? And in the last 2 cases, shouldn't the Code of Conduct also be updated to mention this new document, in order to be legitimately enforceable, given that the people involved aren't required to make a pledge ? ### On my past use of AI for issues Because of this discussion, I guess I should admit that I used Mistral AI to write the last two issues I submitted to the Forgejo repository ([#8564](https://codeberg.org/forgejo/forgejo/issues/8564) & [#8741](https://codeberg.org/forgejo/forgejo/issues/8741)), which I'm sure no one noticed and no one was bothered by, as my only use for it was to feed it my feature request as a simple sentence and have it elaborate on that request in a way that follows the template, which work I double-checked and applied corrections before submitting. Therefore, I also disagree on banning the use of AI for this purpose. ### On my use of AI to write this comment AI was not used at all to write this comment. ### On Gitea's use of AI Is there information on if and how Gitea uses AI ? This might impact the practice of cherry-picking from Gitea to Forgejo. ### On the use of AI chat In addition to auto-completion, I sometimes use AI the same way I would use StackOverflow : to get a small piece of code to get inspiration from to implement something, or to get an explanation on why an error occurs. What about that ? --- Thank you

Gusted commented 2025年08月30日 00:38:57 +02:00

@KaKi87 wrote in #366 (comment):

Does that apply :

It applies to everyone that wants to interact in the Forgejo space that is covered by Forgejo's Code of Conduct.

@KaKi87 wrote in #366 (comment):

And in the last 2 cases, shouldn't the Code of Conduct also be updated to mention this new document, in order to be legitimately enforceable, given that the people involved aren't required to make a pledge ?

It will be mentioned via forgejo/code-of-conduct#25, @earl-warren raised this in forgejo/governance#325 (comment)

@KaKi87 wrote in #366 (comment):

Did anyone actually answer this ?

There's no agreement that bans AI for all purposes in all situations. In the case of auto-complete (as I've seen it being used in the last few years where you begin typing some code or comment and you can accept a suggestion to complete what you want to code) this would fall under that you must document this was used and that you can show you can submit that content under the license (DCO requirement) - it cannot be used for code comments however as it has to convey your own intention and thoughts.

@KaKi87 wrote in https://codeberg.org/forgejo/discussions/issues/366#issuecomment-6806665: > Does that apply : It applies to everyone that wants to interact in the Forgejo space that is covered by Forgejo's Code of Conduct. @KaKi87 wrote in https://codeberg.org/forgejo/discussions/issues/366#issuecomment-6806665: > And in the last 2 cases, shouldn't the Code of Conduct also be updated to mention this new document, in order to be legitimately enforceable, given that the people involved aren't required to make a pledge ? It will be mentioned via https://codeberg.org/forgejo/code-of-conduct/pulls/25, @earl-warren raised this in https://codeberg.org/forgejo/governance/pulls/325#issuecomment-6806194 @KaKi87 wrote in https://codeberg.org/forgejo/discussions/issues/366#issuecomment-6806665: > Did anyone actually answer this ? There's no agreement that bans AI for all purposes in all situations. In the case of auto-complete (as I've seen it being used in the last few years where you begin typing some code or comment and you can accept a suggestion to complete what you want to code) this would fall under that you must document this was used and that you can show you can submit that content under the license (DCO requirement) - it cannot be used for code comments however as it has to convey your own intention and thoughts.

mahlzahn commented 2025年08月30日 00:47:41 +02:00

I try to answer to how I understand the agreement.

@KaKi87 wrote in #366 (comment):

On the use of AI autocomplete

I use LLMs all the time to write code – however, not in the form of "vibe coding" [...] but almost exclusively in the form of inline suggestions [...] By banning AI entirely, such inline auto-complete suggestions would be banned too, which I'd find detrimental.

Did anyone actually answer this ?

As I have the same experience as @pixelcode, I share their opinion and would like some feedback about it.

It is also not mentioned at all in the text at forgejo/governance#325.

If these snippets/suggestions are not actually copyrightable (but maybe they are?), then this should be fine. It would need a disclaimer though that LLM was used, how and that this use does not violate any licensing.

On the use of AI for issues and comments

The abovementioned text also says :

issues [...] and comments on issues [...] intended to be read by people to understand your thoughts and work must not have been generated with AI

Does that apply :

* only to Forgejo team members while carrying out their work as a team member ;
* or only to Forgejo team members whether carrying out their work a team member or participating outside of that perimeter ;
* or also to Forgejo contributors whether they are or aren't members of a Forgejo team ;
* or also to any Forgejo community member participating in any way ?

This applies to everybody interacting in the Forgejo spaces.

And in the last 2 cases, shouldn't the Code of Conduct also be updated to mention this new document, in order to be legitimately enforceable, given that the people involved aren't required to make a pledge ?

Yes. See forgejo/governance#325/files (comment)

On my past use of AI for issues

Because of this discussion, I guess I should admit that I used Mistral AI to write the last two issues I submitted to the Forgejo repository (#8564 & #8741), which I'm sure no one noticed and no one was bothered by, as my only use for it was to feed it my feature request as a simple sentence and have it elaborate on that request in a way that follows the template, which work I double-checked and applied corrections before submitting.

Therefore, I also disagree on banning the use of AI for this purpose.

They are indeed not following the AI agreement and could now, if detected, be treated as violations of the CoC.

On Gitea's use of AI

Is there information on if and how Gitea uses AI ? This might impact the practice of cherry-picking from Gitea to Forgejo.

As far as this is concerned, it seems that the cherry-picking stopped by now.

On the use of AI chat

In addition to auto-completion, I sometimes use AI the same way I would use StackOverflow : to get a small piece of code to get inspiration from to implement something, or to get an explanation on why an error occurs.

What about that ?

If pieces are small, copyright on them is arguable. And thus, AI may still be used for inspiration, learning, etc.

I try to answer to how I understand the agreement. @KaKi87 wrote in https://codeberg.org/forgejo/discussions/issues/366#issuecomment-6806665: > ### On the use of AI autocomplete > > > I use LLMs all the time to write code – however, not in the form of "vibe coding" [...] but almost exclusively in the form of inline suggestions [...] By banning AI entirely, such inline auto-complete suggestions would be banned too, which I'd find detrimental. > > Did anyone actually answer this ? > > As I have the same experience as @pixelcode, I share their opinion and would like some feedback about it. > > It is also not mentioned at all in the [text at forgejo/governance#325](https://codeberg.org/forgejo/governance/pulls/325/files). If these snippets/suggestions are not actually copyrightable (but maybe they are?), then this should be fine. It would need a disclaimer though that LLM was used, how and that this use does not violate any licensing. > ### On the use of AI for issues and comments > > The abovementioned text also says : > > > issues [...] and comments on issues [...] intended to be read by people to understand your thoughts and work must not have been generated with AI > > Does that apply : > > * only to Forgejo team members while carrying out their work as a team member ; > > * or only to Forgejo team members whether carrying out their work a team member or participating outside of that perimeter ; > > * or also to Forgejo contributors whether they are or aren't members of a Forgejo team ; > > * or also to any Forgejo community member participating in any way ? This applies to everybody interacting in the Forgejo spaces. > And in the last 2 cases, shouldn't the Code of Conduct also be updated to mention this new document, in order to be legitimately enforceable, given that the people involved aren't required to make a pledge ? Yes. See https://codeberg.org/forgejo/governance/pulls/325/files#issuecomment-6806194 > ### On my past use of AI for issues > > Because of this discussion, I guess I should admit that I used Mistral AI to write the last two issues I submitted to the Forgejo repository ([#8564](https://codeberg.org/forgejo/forgejo/issues/8564) & [#8741](https://codeberg.org/forgejo/forgejo/issues/8741)), which I'm sure no one noticed and no one was bothered by, as my only use for it was to feed it my feature request as a simple sentence and have it elaborate on that request in a way that follows the template, which work I double-checked and applied corrections before submitting. > > Therefore, I also disagree on banning the use of AI for this purpose. They are indeed not following the AI agreement and could now, if detected, be treated as violations of the CoC. > ### On Gitea's use of AI > > Is there information on if and how Gitea uses AI ? This might impact the practice of cherry-picking from Gitea to Forgejo. As far as this is concerned, it seems that the cherry-picking stopped by now. > ### On the use of AI chat > > In addition to auto-completion, I sometimes use AI the same way I would use StackOverflow : to get a small piece of code to get inspiration from to implement something, or to get an explanation on why an error occurs. > > What about that ? If pieces are small, copyright on them is arguable. And thus, AI may still be used for inspiration, learning, etc.

LWFlouisa commented 2025年09月05日 18:28:37 +02:00

Yea I'm not sure how to answer that question as I consider predictive Ai ( think Naive Bayes ) a different beast from Generative AI. I'm generally speaking not a fan of generative AI.

I could use using Naive Bayes to predict things like measuring malicious traffic, though how much better than is than just a sufficiently technical person, I'm not sure.

Yea I'm not sure how to answer that question as I consider predictive Ai ( think Naive Bayes ) a different beast from Generative AI. I'm generally speaking not a fan of generative AI. I could use using Naive Bayes to predict things like measuring malicious traffic, though how much better than is than just a sufficiently technical person, I'm not sure.

n0toose commented 2026年02月13日 00:46:37 +01:00

Hi all, as there is a series of projects that have explored adding a similar AI policy to that of Forgejo's (and in support of the current status quo and other projects wanting to follow the same footsteps), it might make sense to bring this up in the interest of the greater community and individual communities exploring their options: Funding opportunities could be jeopardized at the moment if the use of GenAI in projects is non-transparent or otherwise, as I'd frame it, reckless/negligent (i.e. deceit or insufficient transparency). See: https://nlnet.nl/foundation/policies/generativeAI/ (Internet Archive) - NLnet has previously supported Forgejo's development.

The document above is provided purely for informational reasons (as people unfamiliar with the Forgejo community take a look at this very thread every now and then for inspiration) and does not intend to reopen a closed discussion. If you feel this is necessary based on the information above (although I'd consider our policy to be stricter than the policy shown), please open a new issue instead.

Secondary source: github.com/manyfold3d/manyfold@7d0326db4b

Hi all, as there is a series of projects that have explored adding a similar AI policy to that of Forgejo's (and in support of the current status quo and other projects wanting to follow the same footsteps), it might make sense to bring this up in the interest of the greater community and individual communities exploring their options: Funding opportunities could be jeopardized at the moment if the use of GenAI in projects is non-transparent or otherwise, as I'd frame it, reckless/negligent (i.e. deceit or insufficient transparency). See: https://nlnet.nl/foundation/policies/generativeAI/ [(Internet Archive)](https://web.archive.org/web/20260212234122/https://nlnet.nl/foundation/policies/generativeAI/) - NLnet has previously supported Forgejo's development. The document above is provided purely for informational reasons (as people unfamiliar with the Forgejo community take a look at this very thread every now and then for inspiration) and does not intend to reopen a closed discussion. If you feel this is necessary based on the information above (although I'd consider our policy to be stricter than the policy shown), please open a new issue instead. Secondary source: https://github.com/manyfold3d/manyfold/commit/7d0326db4b8a25b3e047cceff0065e70865f2303