I think that the policy intention is to moderate how we as a community make use of these tools in our contributions, not to police our upstreams.
If you reviewed the patch that you got from the 3rd party yourself and see that it fixes the reported problem, then I think that including the proper attributions that we already have for upstream patches would be good enough. On the other hand, if it was you as a Fedora contributor who used AI tools to create a patch to deal with a Fedora specific issue, you would need to attribute the LLM work as described by the policy.
What is a “contribution” to Fedora from the POV of this policy ? The policy doesn’t define its scope which is bad. One example is a set of patches in a merge request opened against a package. A merge request shouldn’t be a special case though, an initial “new package” import is also a contribution. Do we have to declare if the tarball we’re importing includes AI generated content ? That would seem highly impractical & unduly burdensome.
It might suggest the scope of “contribution” only covers content authored specifically for Fedora ? That would mean a merge request with a patch cherry-picked from upstream git or bug tracker could be exempt from the AI policy, but a patch authored in Fedora would be in-scope of the policy ? It would somewhat undesirable to have a double-standard for merge requests, depending on what content is present, but it is also undesirable to request patches cherry-picked from upstream be held to a different standard than a tarball acquired from upstream.
A few mins ago I saw an interesting fork of a project, looked at the changelog history a little, suspected the formatting was AI-assisted about half-way down, saw some interesting claims I know weren’t human-typed with file sizes and perf differences, got to the bottom and saw emojis, and dismissed the whole project further.
I don’t know what a solution could be for that, but I’m expecting changelogs and associated code to be good with both the allowance and use of AI-assistance. Prohibiting use is likely unreasonable, but I’m not a fan of reading changelogs or (AI’s expertise) winded descriptions, so I optimize my time by glancing through stuff to check for it. Doing that for a large OS is a different scope, hence stuff better be good!
On a different topic, why should AI-assisted use be permitted for language translation? The author speaks a native language: The project wanting the contribution should be the ones translating, vs pushing outsiders to do it to fit-in. So if contributors want to use AI tools to translate, they should do it outside of a general AI-assisted policy imo (AI-assisted code and language translations should be separate policies assuming the language translations are only providing descriptions of code; AI-assisted code with plaintext translations in strings in a .cpp = AI-assisted code)
This is a great question. We spent a lot of time discussing this as part of strategy2028, since the strategy aims to double the number of weekly active contributors. But in order to measure growth, we need a better definition of a contribution and a contributor. To this end, commops-team is discussing this, as we are in the process of spinning up a Fedora Data Working Group.
Therefore, my view is that this policy should not define what a contribution is. I think it serves our purposes better to cast a wide net, and let our contributor community use their human intuition on what a contribution is. For example, we could spend a lot of time defining git patches and merge requests, but that excludes important work like content creation (e.g. blogs, social media, docs, etc.) and outreach (e.g. public speaking, marketing material, design assets, etc.). The challenge we faced before with defining what a contribution to Fedora is, is that there is a vast amount of things people do in our community. By overemphasizing a particular kind of contribution, we underemphasize other kinds of contribution.
That said, if in three months we are seeing a lot of AI slop in a particular part of Fedora, we can (and should) revise the policy to be more explicit on a particular kind of contribution type.
Speaking for myself, I thought @dherrera’s interpretation was spot-on:
The bulk of value in summarizing changes in Fedora Linux is driven by our existing Project Discussion > Change Proposals process, the Release Notes written by the docs-team and community, and other marketing-team material (e.g. Fedora Magazine posts summarizing highlights from the next release). All of these contributions are heavily involved with humans already. Even if AI is utilized for these things, there is a significant amount of peer review that happens before something “goes live.”
As for changelogs for individual packages, I would suggest this is arguably up to individual maintainers and the use of AI has little to no impact here. Most packages have changelogs that hardly indicate anything except maybe a pull from a more recent upstream version of packaged software. However, some maintainers do an excellent job with writing changelogs already. I do not see AI affecting RPM spec changelogs much. In fact, perhaps some maintainers could use AI to make more thorough RPM spec changelogs in places where there are currently none.
As a quick update, this Council will review the existing policy draft as the final topic of our Matrix meeting this Wednesday (see meeting agenda). As a reminder, the full text that the Council is considering can be found in the Fedora Council Pagure ticket.
Here is an additional note from @amoloney that was posted in a few places:
We are in the 4th week of the Policy Change Process for the proposed AI policy, and nearly a week since we clarified what version of the policy we are discussing.
As we have a Council meeting on Wednesday, I would ask all Council members to please vote in the Pagure ticket before the meeting on the current policy proposed to either accept or reject it. We require a Full Consensus for this policy to pass, and I would like us to use FESCo’s method of voting, with a minor tweak:
+1 is agreement
we will not use a 0 vote
If you are -1 to the current policy proposed, please vote that way. This will automatically trigger that the policy be discussed in the meeting on Wednesday, and the person/people who are -1 MUST be present to provide their reasoning.
If there are any -1 votes, we ALL will need to work together to figure out a path forward for full consensus on a policy on Wednesday’s meeting.
I wanted to share the outcome of today’s Council meeting regarding this proposal. After several weeks of discussion and incorporating feedback from our community into better revisions of the initial proposal, the Fedora Council has approved the latest version of the AI-Assisted Contributions policy formally. The agreed-upon version can be read in this ticket. You can read the full meeting transcript in the meeting log.
So what happens next?
Firstly, on behalf of the Fedora Council I want to thank everyone who took the time to engage with us on this proposal. At times it might have seemed a little intense, and maybe it was , but we have an end result of a policy that we can at least use as a foundation for AI and Fedora that has come from a very large collaborative discussion with our community.
B, I will be posting the outcome of this process to this thread, the mailing list thread and the community blog to keep our community updated on what has happened with this proposal.
Three, @jflory7 will add the agreed policy to the Council Policies page. If there is a more appropriate home for it, please let us know.
A final note; the Fedora Council fully expects this policy to need to be updated over time to stay current with AI technology. The policy change policy will be utilized as and when those changes to this initial policy need to happen.
Thank you all again for contributing to this discussion and ultimately this policy!
Aye aye! Honestly, I cannot imagine any other place for this policy to live. I’ll work on this soon with @jasonbrooks. Mostly making sure I have the exactly right text before converting it to AsciiDoc for the policy doc.
, but we have an end result of a policy that we can at least use as a foundation for AI and Fedora that has come from a very large collaborative discussion with our community.
Honestly, I cannot imagine any other place for this policy to live. I’ll work on this soon with 