Ok, thank you. I appreciate the time and space being given to this topic and for considering all feedback. Feel free to add the snippet as a comment on the Council Pagure ticket page or I suppose I could do so as well, or do you want a summarized version of the post there? It is a bit long.
It is better to keep long-form discussion here and avoid adding comments to the Pagure issue. The purpose of the Pagure issue is for recording official votes by members of the Fedora Council on the final policy text.
Therefore, I suggest we allow time for @jasonbrooks to catch up on this topic next week as the original proposer of the policy. Then, he can post an updated comment to Pagure if we don’t have any other tweaks to make by the end of Tuesday, 14 October.
I will point out that it is unlikely that FESCo, Mindshare, or Council will file code of conduct reports. Being one or two steps removed generally leads to bad reports.
From my lived experience and observations, I strongly disagree.
However, I do think our community has come a long way with Code of Conduct since Marie’s great efforts in 2021/2022. Perhaps instead of implying leadership bodies should be the one to raise issues, it is important to generally support the idea that anyone can raise a CoC report on issues about interpersonal interactions between contributors.
What I want to avoid for the sake of the Code of Conduct Committee is finger-pointing about whether someone allegedly violated the AI policy. We need to have some other mechanism to address noncompliance with the AI policy than Code of Conduct. And actually, I think if we make Code of Conduct enforcement line up with AI policy enforcement, it is going to make people more afraid to experiment.
Ultimately, on the AI policy, “enforcement” is not a “break the rules, get banned” sort of approach. Especially as we roll this policy out, we need to keep an open mind and acknowledge that there will be mistakes, there will be things that we inevitably question, but these things will happen by design. We will work through the issues and determine what enforcement will look like as the issues come up.
To @bookwar’s previous reminder, we cannot try and solve all of the possible problems on Day 0. We have to get to Day 100 first to better understand what complex and tricky problems may pop up in Fedora.
I expect that we will have to work on this per type of contribution.
For example, on Discourse we do expect moderators to take the Council policy and incorporate it into the forum rules somehow, so that forum moderators can deal with it without pinging Council level on every minor occasion. But also can get the issue escalated when required.
I think we had this conversation just recently. And I think FESCo, Council, but also, honestly, every other group in the project, should be able to recognize the need for the Code of Conduct committee involvement, whether it is a need for investigation, or a need for implementation some of the group decisions.
And you can ask Code of Conduct Committee for help or you can recommend others to do it.
This looks awesome to me, @bookwar. I love the way it turns the “preamble” part into a rule, with a clear MAY. I also like the way it handles the MUST/SHOULD issue w/ contributions.
I’m not sure if I understand the purpose of #5, but I don’t have a problem with it.
Thanks for this!
@jasonbrooks If you are happy to take @bookwar’s version without additional changes, mind if you post a new comment on the Fedora Council tracker ticket with the new text, so we can work on organizing a vote by the next Fedora Council meeting?
I feel confident to vote on it as it is today, but I know other Council members who are working on other important things in Fedora other than AI policy might want a little more time to digest and think on this.
As I said on the meeting, I think we need to propose this to the wider community as a new proposal instead of cooking something here and immediately rush to voting. It’s hard for me to keep track of this topic even as a member of the Council who is highly motivated to stay on top of it. I don’t share your sense of urgency for the vote.
When you say “wider community” do you mean widening the scope somehow to people who haven’t paid attention to this thread?
There’s no need to rush, but we should respect our processes. The resolution in the council meeting was to give it a week and then vote on it. If we keep restarting the clock on discussion, and forking into new threads, we’ll never reach a result, and the discussion will become progressively more difficult to follow.
If we need to take a bit more time, that’s fine, but the draft we’ve worked up to is a direct result of the feedback the community has provided in the weeks we’ve already spent discussing this.
FWIW, as somebody who has taken part in and followed the full thread, I think Aleksandra’s latest draft is pretty good. While I don’t agree with everything in it, it sets the right tone, and seems to represent the voices of many groups in this discussion. I’ve held back on further replies because I think it’s in “good enough” territory for now. As others have also stopped replying and suggesting it’s possible that many others feel the same way.
I mean to announce the current proposal at least on devel-announce once more. I understand that restarting the clock on every change might not be worth it, but in this case, I think this is essentially a new version of the proposal that deserves a new announcement. I don’t want to vote on something that was just proposed a couple of days ago.
OK, @amoloney or @jflory7 can you announce the draft again with a pointer to the current version? I think we should still point to this thread so we don’t fragment the discussion further.
I do honestly believe that those who read the first draft in the thread and have been keeping even loose tabs on the discussion during these past weeks will recognize the current draft as a direct, community feedback-enhanced, descendant of that draft.
Would you be willing to take this action item on behalf of the Council?
I’m confused on the ask. Are we simply doing extra communication about the vote, like on the devel list, or are we following the Policy Change Policy?
Proposed changes to Fedora Council policies must be publicly announced on the #council tag on Fedora Discussion and in a Fedora Community Blog post in order to get feedback from the community. After a minimum of two calendar weeks, the Fedora Council may vote on the proposed change using the full consensus voting model. After approval, the change is reflected on the Fedora Council policies page.
I have been out for two months on medical leave and I’m honestly still catching up on a lot. This topic was brewing even before I went out on my medical leave, which is why I was keen to jump in quickly since I came back.
If the ask is to restart the Policy Change Process, I would like to delegate this one out to someone else until I can properly get back on my feet. Restarting the entire process is a lot of work and we’ll need to make sure we track the feedback in a new Fedora Discussion topic, while either keeping this one active or closing it and redirecting conversation to a new topic.
We probably should have discussed those details at the last council meeting. I thought the council just wanted another week before holding the vote, and an additional heads up about that, which you did provide on this thread.
I certainly hope we’re not restarting the process. I think Miro just wants an additional heads up to go out on devel-announce@lists.fedoraproject.org?
I assume something like, “After a few weeks of discussion and adjustments to the the original policy draft, the version linked here will soon be voted on by the council.” I don’t know how messages get sent to that list, the initial one came from @amoloney.
Exactly.
I just sent that. However, devel-announce is moderated, so it might take a while. If a list moderator is reading this, please approve my announcement. Thanks
I’ve approved that email so it has landed to the devel-announce list now too. Here is where I am at with the current policy, and what I would like to see as next/final steps:
- The policy has not changed drastically from what had initially been proposed. As far as I can tell, there is no brand new subject matter introduced the latest revision form the original. Rather, the current proposal has been enhanced to include as much feedback as possible from the original. So to me, there is no need to completely restart the process. Instead, we are continuing on in the current process and making sure that there is clarity on what is being proposed to be voted on.
- I understood from our meeting last week that we were delaying the decision to vote by one week as there was still a lot of discussion happening on the thread, and what the exact policy that we would have to take a vote on was not very clear. At least to me it wasn’t. Our Policy Change Policy only states that a minimum of two weeks must be given for feedback, not that we can only allow two weeks for feedback. In this instance, more time was and is absolutely needed. And I think we are the better for it with the latest version of the policy!

So, with this latest revision now published, I feel we have reached a place where there is a satisfactory* policy proposed, which has come from several revisions to the original from the feedback received. This is community collaboration at work, and while the topic itself is a pretty divisive one, its been great to see the different points of views being stated, and heard, and formed into a policy the project can at least start with regarding AI.
My suggestion for the councils next steps:
Firstly, thank you @churchyard for announcing the current policy version to the lists, to you @jasonbrooks for updating the ticket with the current version and @bookwar for updating this thread with them too. This is exactly the clarity we needed to proceed with this process.
A current version of the policy is now announce, and I would recommend that we (council), continue to monitor the discussion, and plan to vote in the ticket before our next council meeting on Wednesday, 22 October 2025.
We can follow FESCo’s pattern of a -1 vote in the ticket will automatically trigger that the proposal be discussed in the meeting. However, if no -1s are received in the ticket, we will do a vote tally as part of the meeting and can announce any decisions and assign any action items as the result.
*I understand this is not a satisfactory proposal felt by absolutely everyone. However, this one seems to meet a decent middle ground, and I agree with @blc sentiment that the policy currently proposed is ‘good enough’ for now. Personally, I would prefer that the Fedora Project have something in place regarding AI contributions that could help folks understand where and what is an appropriate use of AI in the project than have nothing at all. I fully expect we will need to propose further revisions to any policy we ratify on the subject in the (likely near) future, but until we start with something, we ultimately have nothing ![]()
The policy sounds reasonable. I am +1
Thank you @churchyard! ![]()
This reads as sensible next steps to me. Thanks for summarizing and helping get us on the same page @amoloney.
- Transparency: You MUST disclose the use of AI tools when the
significant part of the contribution is taken from a tool without changes.
You SHOULD disclose the other uses of AI tools, where it might be useful.
Routine use of assistive tools for correcting grammar and spelling, or for
clarifying language, does not require disclosure.
I’m not sure how to deal with third-party contributions which I suspect of
being produced by AI tools, but not being explicitly marked as such by the
third party.
E.g. I, as a packager, find a patch in upstream bug tracker which I’d like to
apply to a Fedora package, but which looks generated. Or an upstream of my
package is known to accept AI-generated code, hence the generated code is
probably contained in the upstream release.
Should I insist on the 3rd-party contributor to provide the AI attribution
before merging it? Or should I myself append a fuzzy disclaimer, like “this
piece of work may contain AI-generated content”? Or should I simply ignore my
opinion and merge the content as it is?