An AI Usage Policy for IPFire

An AI Usage Policy for IPFire

[Michael Tremer]

Hello everyone,

While eating my lunch today I stumbled over the AI Usage Policy that the Ghostty project has come up with. I quite liked it and I think that IPFire should also have a policy for AI usage in place. We have not received such an overwhelming amount of AI-generated patches unlike Ghostty and cURL, but we have received some that have been very low quality and when asked questions, the person who submitted this patch raised his hands and dropped out. This is just a waste of time for everyone involved.

This policy that I have slightly adapted for IPFire demands that any kind of AI usage is allowed, but has to be disclosed. The point is to avoid any kind of low-quality, time-wasting submissions. I too believe that we should make this known upfront so that we can all be on the same page and make the job easy for us in case we need to reject any kind of patch submission.

On the other hand, the policy is encouraging AI usage as there are indeed tasks where AI can help. But just because it is AI-generated does not mean that something is good.

I would like you all to have a look at this and see if this is working for you as well or if you would like to have any changes made to it:

  https://www.ipfire.org/docs/devel/ai-policy

All the best,
-Michael

Re: An AI Usage Policy for IPFire

[Adolf Belka]

Hi Michael,

On 23/01/2026 15:48, Michael Tremer wrote:
> Hello everyone,
> 
> While eating my lunch today I stumbled over the AI Usage Policy that the Ghostty project has come up with. I quite liked it and I think that IPFire should also have a policy for AI usage in place. We have not received such an overwhelming amount of AI-generated patches unlike Ghostty and cURL, but we have received some that have been very low quality and when asked questions, the person who submitted this patch raised his hands and dropped out. This is just a waste of time for everyone involved.
> 
> This policy that I have slightly adapted for IPFire demands that any kind of AI usage is allowed, but has to be disclosed. The point is to avoid any kind of low-quality, time-wasting submissions. I too believe that we should make this known upfront so that we can all be on the same page and make the job easy for us in case we need to reject any kind of patch submission.
> 
> On the other hand, the policy is encouraging AI usage as there are indeed tasks where AI can help. But just because it is AI-generated does not mean that something is good.
> 
> I would like you all to have a look at this and see if this is working for you as well or if you would like to have any changes made to it:

Most of it seems fine to me and I agree with it.

The only concerns are that it refers to pull requests from external users but as far as I am aware we generally don't accept pull requests, certainly not in the GitHub repo. If any IPFire GitHub pull request has any merits then an IPFire developer has to take the pull request and convert it into an IPFire patch submission supplied to the IPFire Development mailing list.

If the intent of pull request as mentioned in the AI Policy is different than what I have described above then it is not clear to me from the policy wording.

Regards,

Adolf.


> 
>    https://www.ipfire.org/docs/devel/ai-policy
> 
> All the best,
> -Michael

Re: An AI Usage Policy for IPFire

[Michael Tremer]

Hello Adolf,

Thanks for reviewing this.

> On 23 Jan 2026, at 17:30, Adolf Belka <adolf.belka@ipfire.org> wrote:
> 
> Hi Michael,
> 
> On 23/01/2026 15:48, Michael Tremer wrote:
>> Hello everyone,
>> While eating my lunch today I stumbled over the AI Usage Policy that the Ghostty project has come up with. I quite liked it and I think that IPFire should also have a policy for AI usage in place. We have not received such an overwhelming amount of AI-generated patches unlike Ghostty and cURL, but we have received some that have been very low quality and when asked questions, the person who submitted this patch raised his hands and dropped out. This is just a waste of time for everyone involved.
>> This policy that I have slightly adapted for IPFire demands that any kind of AI usage is allowed, but has to be disclosed. The point is to avoid any kind of low-quality, time-wasting submissions. I too believe that we should make this known upfront so that we can all be on the same page and make the job easy for us in case we need to reject any kind of patch submission.
>> On the other hand, the policy is encouraging AI usage as there are indeed tasks where AI can help. But just because it is AI-generated does not mean that something is good.
>> I would like you all to have a look at this and see if this is working for you as well or if you would like to have any changes made to it:
> 
> Most of it seems fine to me and I agree with it.

Good!

> The only concerns are that it refers to pull requests from external users but as far as I am aware we generally don't accept pull requests, certainly not in the GitHub repo. If any IPFire GitHub pull request has any merits then an IPFire developer has to take the pull request and convert it into an IPFire patch submission supplied to the IPFire Development mailing list.

The original version used “Pull Request” whenever they talked about a contribution. We don’t normally use those, certainly not using GitHub.

There is however some documentation about PRs in case there are huge patch sets. You know well how good Patchwork is with huge patch sets. It is documented here:

  https://www.ipfire.org/docs/devel/git/pull-requests

We pretty much never use this, but that does not mean that we won’t in the future. So in this sense I kept pull request in one place of the policy. Actually we are talking about any kind of contribution. I hope the text is inclusive of all of this.

> If the intent of pull request as mentioned in the AI Policy is different than what I have described above then it is not clear to me from the policy wording.

We definitely don’t mean GitHub PRs. Those are shit and actually a huge contributor to why so many projects are receiving so many AI slop as they make these drive-by “contributions” so easy.

-Michael

> Regards,
> 
> Adolf.
> 
> 
>>   https://www.ipfire.org/docs/devel/ai-policy
>> All the best,
>> -Michael
> 
> 

Re: An AI Usage Policy for IPFire

[Adolf Belka]

Hi Michael,

On 23/01/2026 18:50, Michael Tremer wrote:
> Hello Adolf,
> 
> Thanks for reviewing this.
> 
>> On 23 Jan 2026, at 17:30, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>
>> Hi Michael,
>>
>> On 23/01/2026 15:48, Michael Tremer wrote:
>>> Hello everyone,
>>> While eating my lunch today I stumbled over the AI Usage Policy that the Ghostty project has come up with. I quite liked it and I think that IPFire should also have a policy for AI usage in place. We have not received such an overwhelming amount of AI-generated patches unlike Ghostty and cURL, but we have received some that have been very low quality and when asked questions, the person who submitted this patch raised his hands and dropped out. This is just a waste of time for everyone involved.
>>> This policy that I have slightly adapted for IPFire demands that any kind of AI usage is allowed, but has to be disclosed. The point is to avoid any kind of low-quality, time-wasting submissions. I too believe that we should make this known upfront so that we can all be on the same page and make the job easy for us in case we need to reject any kind of patch submission.
>>> On the other hand, the policy is encouraging AI usage as there are indeed tasks where AI can help. But just because it is AI-generated does not mean that something is good.
>>> I would like you all to have a look at this and see if this is working for you as well or if you would like to have any changes made to it:
>>
>> Most of it seems fine to me and I agree with it.
> 
> Good!
> 
>> The only concerns are that it refers to pull requests from external users but as far as I am aware we generally don't accept pull requests, certainly not in the GitHub repo. If any IPFire GitHub pull request has any merits then an IPFire developer has to take the pull request and convert it into an IPFire patch submission supplied to the IPFire Development mailing list.
> 
> The original version used “Pull Request” whenever they talked about a contribution. We don’t normally use those, certainly not using GitHub.
> 
> There is however some documentation about PRs in case there are huge patch sets. You know well how good Patchwork is with huge patch sets. It is documented here:
> 
>    https://www.ipfire.org/docs/devel/git/pull-requests
> 
> We pretty much never use this, but that does not mean that we won’t in the future. So in this sense I kept pull request in one place of the policy. Actually we are talking about any kind of contribution. I hope the text is inclusive of all of this.

I feel you are being too optimistic. I suspect any user looking at it will just think of the GitHub type of Pull Request.

I feel that Pull Request in the two lines in the policy should be replaced by something related to Patch Submissions.

> 
>> If the intent of pull request as mentioned in the AI Policy is different than what I have described above then it is not clear to me from the policy wording.
> 
> We definitely don’t mean GitHub PRs. Those are shit and actually a huge contributor to why so many projects are receiving so many AI slop as they make these drive-by “contributions” so easy.

Then I would say we should also have a section in the AI policy that says that we don't accept GitHub Pull Requests whether based on AI or not. Then there could be a link to the documentation about submitting patches. That way we close that door also via the AI Policy.

Regards,

Adolf.

> 
> -Michael
> 
>> Regards,
>>
>> Adolf.
>>
>>
>>>    https://www.ipfire.org/docs/devel/ai-policy
>>> All the best,
>>> -Michael
>>
>>
> 

Re: An AI Usage Policy for IPFire

[Stefan Schantl]

Hello Michael,

thanks for working this out.

I've read through the document and it is very good written. Similar to
Adolf I would clarify a bit more what a "Pull request" is and what kind
of requests we accept and which not.

Best regards,

-Stefan
> Hello everyone,
> 
> While eating my lunch today I stumbled over the AI Usage Policy that
> the Ghostty project has come up with. I quite liked it and I think
> that IPFire should also have a policy for AI usage in place. We have
> not received such an overwhelming amount of AI-generated patches
> unlike Ghostty and cURL, but we have received some that have been
> very low quality and when asked questions, the person who submitted
> this patch raised his hands and dropped out. This is just a waste of
> time for everyone involved.
> 
> This policy that I have slightly adapted for IPFire demands that any
> kind of AI usage is allowed, but has to be disclosed. The point is to
> avoid any kind of low-quality, time-wasting submissions. I too
> believe that we should make this known upfront so that we can all be
> on the same page and make the job easy for us in case we need to
> reject any kind of patch submission.
> 
> On the other hand, the policy is encouraging AI usage as there are
> indeed tasks where AI can help. But just because it is AI-generated
> does not mean that something is good.
> 
> I would like you all to have a look at this and see if this is
> working for you as well or if you would like to have any changes made
> to it:
> 
>   https://www.ipfire.org/docs/devel/ai-policy
> 
> All the best,
> -Michael

Re: An AI Usage Policy for IPFire

[Michael Tremer]

Hello,

Sorry for not replying any earlier…

I wanted to write up some more thoughts about basically closing our GitHub account. This has been a long standing thought that I had since a lot of Open Source projects have taken this step. Possibly for other reasons, but I don’t believe that we are benefitting much from our GitHub account at all.

So initially we started this because we wanted to make sure that IPFire will be available to more people. A GitHub search won’t show us unless we have a copy of our repository, and it was also intended as a backup in case our Git server is down for a moment.

The backup is probably the only thing that is still a valid argument to me. Otherwise, we have no option to disable PRs and we have seen a lot of people who have always been ignoring any hints or even willingly went against it and still opened any issues and PRs there. This has just created extra work with no noticeable outcome.

Other open source projects are prominently moving away from GitHub because of Microsoft’s influence and although this argument is not as strong for as because we are not using GitHub as our primary space for any sources, I agree with the intentions of those projects.

Initially I thought that we should only remove the ipfire-2.x repository, but now looking at it again, I don’t see why else we would host anything there whatsoever. Currently we have libloc and ddns copied there, too:

  https://github.com/orgs/ipfire/repositories

Does anyone have any feelings about this? Should we just close it and therefore the whole PR problem in the test is resolving itself somewhat?

-Michael

> On 25 Jan 2026, at 17:38, Stefan Schantl <stefan.schantl@ipfire.org> wrote:
> 
> Hello Michael,
> 
> thanks for working this out.
> 
> I've read through the document and it is very good written. Similar to
> Adolf I would clarify a bit more what a "Pull request" is and what kind
> of requests we accept and which not.
> 
> Best regards,
> 
> -Stefan
>> Hello everyone,
>> 
>> While eating my lunch today I stumbled over the AI Usage Policy that
>> the Ghostty project has come up with. I quite liked it and I think
>> that IPFire should also have a policy for AI usage in place. We have
>> not received such an overwhelming amount of AI-generated patches
>> unlike Ghostty and cURL, but we have received some that have been
>> very low quality and when asked questions, the person who submitted
>> this patch raised his hands and dropped out. This is just a waste of
>> time for everyone involved.
>> 
>> This policy that I have slightly adapted for IPFire demands that any
>> kind of AI usage is allowed, but has to be disclosed. The point is to
>> avoid any kind of low-quality, time-wasting submissions. I too
>> believe that we should make this known upfront so that we can all be
>> on the same page and make the job easy for us in case we need to
>> reject any kind of patch submission.
>> 
>> On the other hand, the policy is encouraging AI usage as there are
>> indeed tasks where AI can help. But just because it is AI-generated
>> does not mean that something is good.
>> 
>> I would like you all to have a look at this and see if this is
>> working for you as well or if you would like to have any changes made
>> to it:
>> 
>>   https://www.ipfire.org/docs/devel/ai-policy
>> 
>> All the best,
>> -Michael
> 

Re[2]: An AI Usage Policy for IPFire

[Jon Murphy]

I would prefer to keep the ipfire-2.x repository on Github.  For me, 
Github is much easier to work with and search.

If it helps, I volunteer to keep an eye on push requests, respond to 
them as needed, and then close them.

Jon


------ Original Message ------
From "Michael Tremer" <michael.tremer@ipfire.org>
To "Stefan Schantl" <stefan.schantl@ipfire.org>
Cc development@lists.ipfire.org
Date 1/26/2026 11:13:56 AM
Subject Re: An AI Usage Policy for IPFire

>Hello,
>
>Sorry for not replying any earlier…
>
>I wanted to write up some more thoughts about basically closing our GitHub account. This has been a long standing thought that I had since a lot of Open Source projects have taken this step. Possibly for other reasons, but I don’t believe that we are benefitting much from our GitHub account at all.
>
>So initially we started this because we wanted to make sure that IPFire will be available to more people. A GitHub search won’t show us unless we have a copy of our repository, and it was also intended as a backup in case our Git server is down for a moment.
>
>The backup is probably the only thing that is still a valid argument to me. Otherwise, we have no option to disable PRs and we have seen a lot of people who have always been ignoring any hints or even willingly went against it and still opened any issues and PRs there. This has just created extra work with no noticeable outcome.
>
>Other open source projects are prominently moving away from GitHub because of Microsoft’s influence and although this argument is not as strong for as because we are not using GitHub as our primary space for any sources, I agree with the intentions of those projects.
>
>Initially I thought that we should only remove the ipfire-2.x repository, but now looking at it again, I don’t see why else we would host anything there whatsoever. Currently we have libloc and ddns copied there, too:
>
>   https://github.com/orgs/ipfire/repositories
>
>Does anyone have any feelings about this? Should we just close it and therefore the whole PR problem in the test is resolving itself somewhat?
>
>-Michael
>
>>  On 25 Jan 2026, at 17:38, Stefan Schantl <stefan.schantl@ipfire.org> wrote:
>>
>>  Hello Michael,
>>
>>  thanks for working this out.
>>
>>  I've read through the document and it is very good written. Similar to
>>  Adolf I would clarify a bit more what a "Pull request" is and what kind
>>  of requests we accept and which not.
>>
>>  Best regards,
>>
>>  -Stefan
>>>  Hello everyone,
>>>
>>>  While eating my lunch today I stumbled over the AI Usage Policy that
>>>  the Ghostty project has come up with. I quite liked it and I think
>>>  that IPFire should also have a policy for AI usage in place. We have
>>>  not received such an overwhelming amount of AI-generated patches
>>>  unlike Ghostty and cURL, but we have received some that have been
>>>  very low quality and when asked questions, the person who submitted
>>>  this patch raised his hands and dropped out. This is just a waste of
>>>  time for everyone involved.
>>>
>>>  This policy that I have slightly adapted for IPFire demands that any
>>>  kind of AI usage is allowed, but has to be disclosed. The point is to
>>>  avoid any kind of low-quality, time-wasting submissions. I too
>>>  believe that we should make this known upfront so that we can all be
>>>  on the same page and make the job easy for us in case we need to
>>>  reject any kind of patch submission.
>>>
>>>  On the other hand, the policy is encouraging AI usage as there are
>>>  indeed tasks where AI can help. But just because it is AI-generated
>>>  does not mean that something is good.
>>>
>>>  I would like you all to have a look at this and see if this is
>>>  working for you as well or if you would like to have any changes made
>>>  to it:
>>>
>>>    https://www.ipfire.org/docs/devel/ai-policy
>>>
>>>  All the best,
>>>  -Michael
>>
>
>

Re: An AI Usage Policy for IPFire

[Michael Tremer]

Hello Jon,

> On 26 Jan 2026, at 20:17, Jon Murphy <jon.murphy@ipfire.org> wrote:
> 
> 
> I would prefer to keep the ipfire-2.x repository on Github.  For me, Github is much easier to work with and search.

git.ipfire.org <http://git.ipfire.org/> has a great search. It simply is a grep across the code base which does not try to be smart.

What are the benefits of using the GitHub search over this and what other features do you require for your work when you say it is easier to work with?

> If it helps, I volunteer to keep an eye on push requests, respond to them as needed, and then close them.
> 
> Jon
> 
> 
> ------ Original Message ------
> From "Michael Tremer" <michael.tremer@ipfire.org>
> To "Stefan Schantl" <stefan.schantl@ipfire.org>
> Cc development@lists.ipfire.org
> Date 1/26/2026 11:13:56 AM
> Subject Re: An AI Usage Policy for IPFire
> 
>> Hello,
>> 
>> Sorry for not replying any earlier…
>> 
>> I wanted to write up some more thoughts about basically closing our GitHub account. This has been a long standing thought that I had since a lot of Open Source projects have taken this step. Possibly for other reasons, but I don’t believe that we are benefitting much from our GitHub account at all.
>> 
>> So initially we started this because we wanted to make sure that IPFire will be available to more people. A GitHub search won’t show us unless we have a copy of our repository, and it was also intended as a backup in case our Git server is down for a moment.
>> 
>> The backup is probably the only thing that is still a valid argument to me. Otherwise, we have no option to disable PRs and we have seen a lot of people who have always been ignoring any hints or even willingly went against it and still opened any issues and PRs there. This has just created extra work with no noticeable outcome.
>> 
>> Other open source projects are prominently moving away from GitHub because of Microsoft’s influence and although this argument is not as strong for as because we are not using GitHub as our primary space for any sources, I agree with the intentions of those projects.
>> 
>> Initially I thought that we should only remove the ipfire-2.x repository, but now looking at it again, I don’t see why else we would host anything there whatsoever. Currently we have libloc and ddns copied there, too:
>> 
>>  https://github.com/orgs/ipfire/repositories
>> 
>> Does anyone have any feelings about this? Should we just close it and therefore the whole PR problem in the test is resolving itself somewhat?
>> 
>> -Michael
>> 
>>> On 25 Jan 2026, at 17:38, Stefan Schantl <stefan.schantl@ipfire.org> wrote:
>>> 
>>> Hello Michael,
>>> 
>>> thanks for working this out.
>>> 
>>> I've read through the document and it is very good written. Similar to
>>> Adolf I would clarify a bit more what a "Pull request" is and what kind
>>> of requests we accept and which not.
>>> 
>>> Best regards,
>>> 
>>> -Stefan
>>>> Hello everyone,
>>>> 
>>>> While eating my lunch today I stumbled over the AI Usage Policy that
>>>> the Ghostty project has come up with. I quite liked it and I think
>>>> that IPFire should also have a policy for AI usage in place. We have
>>>> not received such an overwhelming amount of AI-generated patches
>>>> unlike Ghostty and cURL, but we have received some that have been
>>>> very low quality and when asked questions, the person who submitted
>>>> this patch raised his hands and dropped out. This is just a waste of
>>>> time for everyone involved.
>>>> 
>>>> This policy that I have slightly adapted for IPFire demands that any
>>>> kind of AI usage is allowed, but has to be disclosed. The point is to
>>>> avoid any kind of low-quality, time-wasting submissions. I too
>>>> believe that we should make this known upfront so that we can all be
>>>> on the same page and make the job easy for us in case we need to
>>>> reject any kind of patch submission.
>>>> 
>>>> On the other hand, the policy is encouraging AI usage as there are
>>>> indeed tasks where AI can help. But just because it is AI-generated
>>>> does not mean that something is good.
>>>> 
>>>> I would like you all to have a look at this and see if this is
>>>> working for you as well or if you would like to have any changes made
>>>> to it:
>>>> 
>>>>   https://www.ipfire.org/docs/devel/ai-policy
>>>> 
>>>> All the best,
>>>> -Michael
>>> 
>> 
>> 

Re: An AI Usage Policy for IPFire

[Adolf Belka]

Hallo,

On 26/01/2026 18:13, Michael Tremer wrote:
> Hello,
> 
> Sorry for not replying any earlier…
> 
> I wanted to write up some more thoughts about basically closing our GitHub account. This has been a long standing thought that I had since a lot of Open Source projects have taken this step. Possibly for other reasons, but I don’t believe that we are benefitting much from our GitHub account at all.
> 
> So initially we started this because we wanted to make sure that IPFire will be available to more people. A GitHub search won’t show us unless we have a copy of our repository, and it was also intended as a backup in case our Git server is down for a moment.
> 
> The backup is probably the only thing that is still a valid argument to me. Otherwise, we have no option to disable PRs and we have seen a lot of people who have always been ignoring any hints or even willingly went against it and still opened any issues and PRs there. This has just created extra work with no noticeable outcome.

I have never seen anyone who has posted a PR on our GitHub page ever attempting to submit patches on our mailing list let alone starting a discussion.  There is a link to the IPFire web site at the top of the GitHub page and in the Readme there are several links pointing to various locations giving info on how to support/contribute etc

I believe those users who submit PR's in GitHub do that elsewhere in other projects and are not willing to change to follow the IPFire approach. We have had that with other users who have said, here is my patch done my way, if you want it done differently then it is up to us to re-write it.

> 
> Other open source projects are prominently moving away from GitHub because of Microsoft’s influence and although this argument is not as strong for as because we are not using GitHub as our primary space for any sources, I agree with the intentions of those projects.
> 
> Initially I thought that we should only remove the ipfire-2.x repository, but now looking at it again, I don’t see why else we would host anything there whatsoever. Currently we have libloc and ddns copied there, too:

I think we should completely remove it. I don't believe we will lose much in not having it.

Anyone doing a search for IPFire will find our web site, community, git repo etc long before they find the github search result.

> 
>    https://github.com/orgs/ipfire/repositories
> 
> Does anyone have any feelings about this? Should we just close it and therefore the whole PR problem in the test is resolving itself somewhat?

Maybe. Our documentation talks about Patch Submission and if someone wants to do an update we ask them to submit a patch so I think the policy would be better aligned with the wording Patch Submission rather than PR. Not a deal breaker for me and the worst is that we end up with having to explain to users that PR means Patch Submission for the IPFire AI Policy.

Regards,

Adolf.

> 
> -Michael
> 
>> On 25 Jan 2026, at 17:38, Stefan Schantl <stefan.schantl@ipfire.org> wrote:
>>
>> Hello Michael,
>>
>> thanks for working this out.
>>
>> I've read through the document and it is very good written. Similar to
>> Adolf I would clarify a bit more what a "Pull request" is and what kind
>> of requests we accept and which not.
>>
>> Best regards,
>>
>> -Stefan
>>> Hello everyone,
>>>
>>> While eating my lunch today I stumbled over the AI Usage Policy that
>>> the Ghostty project has come up with. I quite liked it and I think
>>> that IPFire should also have a policy for AI usage in place. We have
>>> not received such an overwhelming amount of AI-generated patches
>>> unlike Ghostty and cURL, but we have received some that have been
>>> very low quality and when asked questions, the person who submitted
>>> this patch raised his hands and dropped out. This is just a waste of
>>> time for everyone involved.
>>>
>>> This policy that I have slightly adapted for IPFire demands that any
>>> kind of AI usage is allowed, but has to be disclosed. The point is to
>>> avoid any kind of low-quality, time-wasting submissions. I too
>>> believe that we should make this known upfront so that we can all be
>>> on the same page and make the job easy for us in case we need to
>>> reject any kind of patch submission.
>>>
>>> On the other hand, the policy is encouraging AI usage as there are
>>> indeed tasks where AI can help. But just because it is AI-generated
>>> does not mean that something is good.
>>>
>>> I would like you all to have a look at this and see if this is
>>> working for you as well or if you would like to have any changes made
>>> to it:
>>>
>>>    https://www.ipfire.org/docs/devel/ai-policy
>>>
>>> All the best,
>>> -Michael
>>
> 
> 

Re: An AI Usage Policy for IPFire

[Michael Tremer]

Hello,

> On 26 Jan 2026, at 20:21, Adolf Belka <adolf.belka@ipfire.org> wrote:
> 
> Hallo,
> 
> On 26/01/2026 18:13, Michael Tremer wrote:
>> Hello,
>> Sorry for not replying any earlier…
>> I wanted to write up some more thoughts about basically closing our GitHub account. This has been a long standing thought that I had since a lot of Open Source projects have taken this step. Possibly for other reasons, but I don’t believe that we are benefitting much from our GitHub account at all.
>> So initially we started this because we wanted to make sure that IPFire will be available to more people. A GitHub search won’t show us unless we have a copy of our repository, and it was also intended as a backup in case our Git server is down for a moment.
>> The backup is probably the only thing that is still a valid argument to me. Otherwise, we have no option to disable PRs and we have seen a lot of people who have always been ignoring any hints or even willingly went against it and still opened any issues and PRs there. This has just created extra work with no noticeable outcome.
> 
> I have never seen anyone who has posted a PR on our GitHub page ever attempting to submit patches on our mailing list let alone starting a discussion.  There is a link to the IPFire web site at the top of the GitHub page and in the Readme there are several links pointing to various locations giving info on how to support/contribute etc
> 
> I believe those users who submit PR's in GitHub do that elsewhere in other projects and are not willing to change to follow the IPFire approach. We have had that with other users who have said, here is my patch done my way, if you want it done differently then it is up to us to re-write it.

I absolutely agree. Although I don’t want to completely deny people dropping of a quick fix to a small problem, we cannot tolerate the kind of drive-by submissions that we have seen. There has never been anything good coming out of them.

If someone does not really want to spend the time to subscribe to our mailing list to email a patch, I suppose that their fix is really not important to them.

We will have to have a hurdle to filter out these things or otherwise we will create too much work for ourselves.

>> Other open source projects are prominently moving away from GitHub because of Microsoft’s influence and although this argument is not as strong for as because we are not using GitHub as our primary space for any sources, I agree with the intentions of those projects.
>> Initially I thought that we should only remove the ipfire-2.x repository, but now looking at it again, I don’t see why else we would host anything there whatsoever. Currently we have libloc and ddns copied there, too:
> 
> I think we should completely remove it. I don't believe we will lose much in not having it.
> 
> Anyone doing a search for IPFire will find our web site, community, git repo etc long before they find the github search result.

I only checked this now… When typing in “IPFire git” into Google, I am getting GitHub as the first hot. On there, there is pretty much nothing. It looks like the project is *very* idle, which is absolutely not true. This might be potentially harmful for the project’s public image.

>>   https://github.com/orgs/ipfire/repositories
>> Does anyone have any feelings about this? Should we just close it and therefore the whole PR problem in the test is resolving itself somewhat?
> 
> Maybe. Our documentation talks about Patch Submission and if someone wants to do an update we ask them to submit a patch so I think the policy would be better aligned with the wording Patch Submission rather than PR. Not a deal breaker for me and the worst is that we end up with having to explain to users that PR means Patch Submission for the IPFire AI Policy.

Patch submission is great for me. That is term that is broad enough and for any specifics there is more documentation on how to actually submit smaller and larger changes.

-Michael

> 
> Regards,
> 
> Adolf.
> 
>> -Michael
>>> On 25 Jan 2026, at 17:38, Stefan Schantl <stefan.schantl@ipfire.org> wrote:
>>> 
>>> Hello Michael,
>>> 
>>> thanks for working this out.
>>> 
>>> I've read through the document and it is very good written. Similar to
>>> Adolf I would clarify a bit more what a "Pull request" is and what kind
>>> of requests we accept and which not.
>>> 
>>> Best regards,
>>> 
>>> -Stefan
>>>> Hello everyone,
>>>> 
>>>> While eating my lunch today I stumbled over the AI Usage Policy that
>>>> the Ghostty project has come up with. I quite liked it and I think
>>>> that IPFire should also have a policy for AI usage in place. We have
>>>> not received such an overwhelming amount of AI-generated patches
>>>> unlike Ghostty and cURL, but we have received some that have been
>>>> very low quality and when asked questions, the person who submitted
>>>> this patch raised his hands and dropped out. This is just a waste of
>>>> time for everyone involved.
>>>> 
>>>> This policy that I have slightly adapted for IPFire demands that any
>>>> kind of AI usage is allowed, but has to be disclosed. The point is to
>>>> avoid any kind of low-quality, time-wasting submissions. I too
>>>> believe that we should make this known upfront so that we can all be
>>>> on the same page and make the job easy for us in case we need to
>>>> reject any kind of patch submission.
>>>> 
>>>> On the other hand, the policy is encouraging AI usage as there are
>>>> indeed tasks where AI can help. But just because it is AI-generated
>>>> does not mean that something is good.
>>>> 
>>>> I would like you all to have a look at this and see if this is
>>>> working for you as well or if you would like to have any changes made
>>>> to it:
>>>> 
>>>>   https://www.ipfire.org/docs/devel/ai-policy
>>>> 
>>>> All the best,
>>>> -Michael
>>> 
>