Meeting started at 2026-07-15 14:01:06 UTC

The Meeting name is 'Fedora Council Bi-Weekly Meeting'

!hi

Aoife Moloney: Aoife Moloney (amoloney)

!hi

Petr Bokoc: Petr Bokoč (pbokoc)

!hi

Peter Boy (ServerWG, Docs): Peter Boy (pboy)

hiya Petr and Peter :)

Good afternoon :)

!hi

bookwar: Aleksandra Fedorova (bookwar) - she / her / hers

!hi

Sorry, could not get info from FASJSON (code 500)

oh that's fun

I guess you get to leave :D

freedom.gif

!hi

(just for funsies)

nimbinatus: Laura Santamaria (nimbinatus) - she / her / hers

You can do whatever you want to FAS Jason, he ain't snitchin

Oh, nvm then

lol

!hi

Fabio Valentini 🌈: Fabio Valentini (decathorpe) - he / him / his

I know we dont have Jef today, unsure about Justin and Miro and its v.late for Akash

Freedom?

In this economy?

I'll see myself out

one can dream ;)

Yeah, the American dream is to live alone debt free

From what I heard

Also let me fix the topic for you

!hi

🇵🇱 | Nik Nikovsky [unreachable on 26/8/26]: Nik Nikovsky (niknikovsky) - he / him / his

Hope this doesn't mess with anyone or anything

thank you!

ok we will proceed, we have a few items to discuss

** #410 - Abolish Fedora Contributor Agreement

* Ticket Discussions:

** #558 - Fedora Forge Useage Policy

https://forge.fedoraproject.org/council/tickets/issues/558

** #513 - Conflict of Interest Guidelines

https://forge.fedoraproject.org/council/tickets/issues/513

https://forge.fedoraproject.org/council/tickets/issues/410

* Next Meeting Topics

*Open Floor

Anyone have anything they need/want to flag?

I do have one item

Anything outside of the agenda I assume?

correct, yes. This section is to remind us to do something or announce a something is coming up or has happened

I have one, but I don't think it's Council business

That would be to modernize the whatcanidoforfedora.org page

But I think that's either a topic for a Design or Intra meeting

Yeah its not for here. Maybe Join SIG might be able to point you in the right direction AFAIK some folks there might use that page as a good starting point for new contributors

I think we should push this towards the join sig, but I think I could bring it up as a ticket in the design forge.

*Reminder* We have one ready for vote ticket in our tracker https://forge.fedoraproject.org/council/-/projects/2

logging into FAS is taking me a minute today, but will vote as soon as I can get in...

Is it me or is this ticket and [#56](https://forge.fedoraproject.org/design/tickets/issues/56) on the design forge related

the vote is for not doing anything as a council

we dont need to vote now, just there is a topic in our voting category so can all council members take an action to review the ticket and see whether we need to bring it to a meeting or not

ah, ok, I can see that now

It sounds like just making sure it gets resolved is good enough versus talking about it sync in a meeting? And it looks to me like 56 is related now (and may not have been before)

I don't think 56 should be pulled in here

^^yes. this is a reminder that there is a ticket that needs attention. I have some concerns about it, but will add them as comments and if we need to bring it into a meeting for wider discussion we can

I think the current issue has an answer "can we change the license on fedora logos - no" -> Close.

Any other reminders or announcements?

Justin Wheeler: provided an overview of a doc thats currently private. Id like to make that doc public

(Sorry to bash in, just wanted to let everyone know)

https://forge.fedoraproject.org/design/tickets/issues/79

I'm fairly certain you could just make it a one liner.

"If there's a conflict of interest, back off and let someone else handle it"

I don't have access to the google doc, but was there a reason the doc was private originally?

Was it the legal considerations that Jef was waiting on?

I have no idea but I suspect it was just to have a working copy going maybe

I hope not because this makes it into a deeper thing than we probably need

>I'm in private consultation with legal about some aspects of the existing project procedures that materially read on conflict of interest policy details,

I was just noting what he commented:

This, but we need a *little* bit more as council for the project to lean on when groups find themselves in situations that might have a conflict of interest issue

it doesn't *sound* like it would be a private thing, but figured I'd ask

I wouldn't like such a requirement

I'm guessing like a definition of a conflict of interest

I'm guessing like a definition of a conflict of interest as well

So maybe moving this public to get more feedback on is needed now

When my interest as a CI Engineer to enable gating tests in Fedora is in conflict with someone else's interest in removing all tests from Fedora, I am not going to back away just because I am interested in the topic :)

!proposal Move the Conflict of Interest guidelines draft public for a feedback period of two weeks and reasses at the next Council meeting

Vote time?

There we go

I am actually not convinced that we need such a policy in Fedora

Thanks 🇵🇱 | Nik Nikovsky [unreachable on 26/8/26] but this is not a vote, this was a proposal to council members on where we are going to leave this topic at in this meeting

But it kind of depends on the scope of the proposed policy

My main concern is ensuring there wasn't a specific reason it was private. But if no one else is specifically concerned, then I'm +1 on moving it to public

I see, the idea command is the closest thing this bot has

Dont worry we dont need a command for that, we can manage fine :)

+1 but don't enact it until we can sync and ratify the scope and contents of the policy

Just making it easier for the summary bot (yw)

The new bot does pretty well without the meetbot summary tags, tbh

So, the next step - we are waiting for Jef and a public draft?

I'd say so

but going back, I think @bookwar's concern can be discussed in the draft where the community can comment?

Personally I only see a 'conflict of interest' instance is where or when a person or group has the ability to make a decision that will significantly impact someones ability to contribute to the project

those decisions should not be taken lightly and do need some form of guidelines for that group to use, and it could very well be -> Ticket to council

We should publish the draft on discourse

sorry I missed that comment

Even then, I can significantly reduce someone elses's ability to contribute via voting on AI-policy. But it is not a conflict of interest, it is doing the job.

So it is a bit tricky to formalize

touche ;)

we need better wordsmithing, but I think we agree on the spirit of what the guidelines should try help with

So proposal? Post draft on discourse for 2 weeks, reasses next council meeting after public feedback period where its at?

SGTM

?

sorry, Sounds Good To Me

Full disclosure, I havent read it all yet :/

but I am +1 to removing the archiving policy part

tbh, I do like archiving as a non-destructuve action which just shows that there was no activity on the code or from the group in a certain amount of time

I feel like it is valuable info for a contributor

I'd argue that this should only happen for other reasons, not just inactivity

(like "user account disabled" or "SIG disbanded")

Could we keep the archiving and just change it from a mandatory 'after 6 months' to more of a best practice, eg If you are no longer able to maintain your repo, please archive it....or something a bit more Fedora-ish :)

Fabio Valentini 🌈: we never ever have SIGs disbanded though. People just stop showing up

oh I like that Fabio Valentini 🌈

The only active orphaning process we have is for packages

not true, I disbanded *two* SIGs already ;)

niknikovsky gave a cookie to decathorpe. They now have 176 cookies, 14 of which were obtained in the Fedora 44 release cycle

I'd say it please archive it if you can't work on it or we will do so after 12 months

I feel like "Infra team reserves the right to archive a repo after a year of inactivity" is a pretty safe statement to be honest. It doesn't mean mandatory clean up of everything. But it also gives us the way to deal with orphaned projects

I just want to highlight that Jef added some notes to the ticket, too, with requests for specific additions (e.g., dealing with specific remixes)

+1 bookwar & 🇵🇱 | Nik Nikovsky [unreachable on 26/8/26]

Yes, if you know what you re doing, you can manage archiving youself. But _the right_ for infra team to do something stays.

Is Jef's concerns covered in the Edge Cases part?

(Im reading the policy now, it looks very good)

So I'm not sure. The concern that I think might be there is this might cause the existing work to halt while the exception process goes through

It's this piece, at the end of his comment:

>I would suggest that this is a council approval action, as bringing certain remixes closer to the project is a strategic decision. Remixes as a group might be considered edge cases that infrastruture takes to leadership, but if so then, this needs to be made explicit in the text concerning edge process.

And I suspect that, with the whole sandbox discussion, this may need to get modified anyway 🤷‍♀️ I look at all docs like this as living ones. We can always request and discuss updates when we reach that point.

I think _if_ we approve the Sandbox framework, we can include it explicitly in the policy. BUt for now it does seems like an "edge case" decision which needs to be done case by case

I would like to remind council that we are running a online service, without any active policy. Just on say so basis...

Neal Gompa (Fedora): please elaborate on your concerns. Why do you see Fedora Infra team's right to archive a repo as a threat?

for a first pass, to be honest, I think it's good to ship with the addition of right-to-archive (with reasons and a way to request a review if you disagree)

So like if a member wants to test if a modified action works but doesn't want to wait for a membership

Also I think we could do something for temporary repositories?

Up to you

Couple of proposals as were running out of time for this meeting:

1. Fedora Council formally takes ownership of finalising and publishing the Fedora Forge Usage Policy

if "unarchive" remains a self-service action for people with access rights on that org/repo, that would make basically all my concerns moot. but that's currently not explicit in the policy.

2. I think Jefs concerns are valid, but likely covereed, or coverable in the edge cases scenario

there's a very big difference here... effectively telling people that they believe they know what kind of activity is reasonable to trigger archiving is the problem

I think this is by design in Forgejo, org owners can do whatevet with org repos.

3. We dont include a tinmeline on archiving inactive repos. Lets just see what happens

Disagree here in that there needs to be a statement that archival *could* happen, with reasons and a way to appeal. But it can be very lightweight ("infra team may open an issue to warn that a repository will be archived in two weeks if not responded to by an owner. If you wish to reopen, you can open a ticket against /infra" or similar

I don't care that unarchival may or may not be self-service, because that's not really the point here

or I guess just unarchive if that's already there

the problem is that it implies that fedora infra knows what "active" looks like

Couldn't the owner just unarchive the repo when they're ready to return?

Yes, that was the second comment. I didn't know it was already enabled

THis is a good point, we should contact the owner first archive if no response.

I'm just guessing based off of GitHub

I'd say 11 months in contact the owner to give them a month to respond

And close if no response

12 months of perceived inactivity and none of the repo owners is reachable

Yes, they could. So I agree with Neal Gompa (Fedora) here that mandating a timeframe of inactivity that your repo gets archived after is prob a bit of a waste of time

it just looks unnecessarily restrictive

We could let the community hunt for inactive repos

for example, fedora kde has repos that don't get touched for years in our sig org

We could!

they just simply don't change that often

if this policy went into effect, I'd probably pull everything out rather than deal with that

Is there a reason why it doesn't work to just have infra open an issue on the repo asking if there's activity and whether it can be archived with a lazy consensus deadline?

simple to respond to, lightweight policy

it's also unnecessary busywork

Id prefer to recommend a best practice of archiving your own repo if you cant maintain it or dont want to, rather than having an 'After X time, we might close this for you'

what does it actually _do_ for you?

Limited storage space

Nothing for you, but for a contributor it lets them know this project is likely abandoned

My understanding from the preamble to the document is that there isn't the same unlimited space as pagure

"archive" does nothing for storage use though. it's just a read-only switch.

perhaps I'm misunderstanding

true

decrease clutter in the forge, remove open trackers accessible to spammer accounts and some more

I asked about resourcing issues. ATM there is no issues with active, but not 'busy' repos

Is it useful at all to archive a repo, if the org is already active?

I don't think infra should decide what counts as "clutter" ;)

archive is a useful flag for a new contributor or user that something isn't maintained

if a SIG is dormant, archiving the organization makes sense, but archiving individual repositories just doesn't have a sensible policy in our structure

if a SIG is dormant, archiving the organization makes sense, but force-archiving individual repositories just doesn't have a sensible policy in our structure

if a SIG is dormant, archiving the organization makes sense, but force-archiving individual repositories just doesn't make sense as a policy in our structure

I am not representing only infra, but in general new contributors complain about how pagure.io was used and organized...

For me there is implicit expectation that Fedora Infra uses common sense when does whatever admin actions. So I am a bit concerned that you think that their right to archive means "we close everything not even checking what we are doing"

We are at time, so time to action some stuff

because the problem is the declaration of a timeframe to do it, not that they can do it at all

and again, individual projects don't make sense to archive if a SIG has gone inactive, you'd want to archive the organization instead

Without explicit timeline it would be worse, like Fedora Infra can make whatever with your repos

!proposal: Council are formally taking over the finalising and publishing of the Fedora Forge Usage Policy. There is still some uncertainly around archiving inactive repositories. We will need to continue this discussion elsewhere and find a resolution before we will puplish the policy under the Policy Change Policy framework (will link)

For the record, I'm giving a vote of confidence to infra to do the right thing by the project. As an user and contributor, I *like* having things that aren't in active development archived. It helps me understand where I can help contribute or where the work of a SIG is currently happening so I can focus my limited contribution time.

!proposal: Council are formally taking over the finalising and publishing of the Fedora Forge Usage Policy. There is still some uncertainly around archiving inactive repositories. We will need to continue this discussion elsewhere and find 8a resolution before we will publish the policy under the Policy Change Policy framework (will link)

!Topic Next Meeting

we will discuss the remaining agenda item async and in the next meeting

thanks for running the meeting, Aoife Moloney !

nimbinatus has already given cookies to amoloney during the F44 timeframe

sorry, we have another meeting in this room and we always spill over into it :(

humaton gave a cookie to amoloney. They now have 115 cookies, 10 of which were obtained in the Fedora 44 release cycle

we can talk more in the council room if people want, and thank you all for your participation today!

still doesn't work?