Fedora forge usage policy #558
Labels
No labels
category
budget
category
code-of-conduct
category
docs
category
elections
category
events
category
initiatives
category
mindshare
category
policies
category
spending-request
category
Strategy Summit
category
trademarks
Next Meeting
state
resolved
good first issue
help wanted
needs
changes
needs
reporter feedback
needs
triage
needs
vote
role
engineering
role
fca
role
foa
role
fpl
role
initiative lead
role
mindshare
scope
bug
scope
improvement
scope
new
state
approved
state
blocked
state
duplicate
state
invalid
state
wontfix
No milestone
No project
No assignees
13 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
council/tickets#558
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Create Fedora forge usage policy
Background
As we are finalizing work on the new forge, some of our contributors are already using it. We need a usage policy. I took the liberty of creating a draft
Details
The forge usage policy is approved and available.
Summary
Fedora users and contributors have clear guidelines for hosting repositories on our forge.
Thanks, amazing job on the draft!
Question: Does Fedora Forge allow bringing "your own" Action workers? Can organizations manage them indepently from Forge admins? Do we want a policy to cover that as well?
For example, let's say we grant the "exceptional" status to FreeIPA. But it can not fit into the current limits of the Forge Action runners. Can that exception come with the requirement that the project brings its own CI resources?
Thank you!
But I cannot create projects within, other than by forking, correct? This is not clear to me from the text (perhaps I missed it).
Could we add a link to such statements? E.g. is it https://forge.fedoraproject.org/infra/tickets or https://forge.fedoraproject.org/forge/forge/issues
Did some updates, added section on bring your own runners. And some links.
We are still missing some docs pages so some links are pointing to the issue tracker.
It's WIP, if you want just enable wiki on any repo in this org and I can copy the .md file there so anybody in this org can edit it.
The draft is on the forge/forge wiki. I don't seem to be able to edit it.
The CI/CD changes on shared runners seem to have left over the original, so some info is now duplicated.
@churchyard wrote in #558 (comment):
We can move it anywhere, just enable wiki in any repo in this org. Than its git clone the forge wiki and cp.
Fixed.
This seems a bit aggressive.
@gotmax23 wrote in #558 (comment):
What would be your suggestion? A year?
I would assume that the archiving won't happen without at least an attempt to send a notification.
@humaton Can we agree that the archiving action can only be applied if we made an attempt to contact the repo owner a week in advance?
That's more reasonable, but what is the function of archiving repositories in the first place?
This policy looks good to me.
For the archiving part, maybe we do could something like:
But really, it should be fairly easy to request un-archiving repos so we might as well make it an automatic thing so that we don't have to think about it.
+1 to the policy proposal draft. It provides essential context for the Fedora Forge.
To make this official and for the Council votes to mean something, we must follow the Policy Change Policy:
Next Steps for Approval
@humaton: Do you have the capacity to write the short Community Blog post and open the Discussion topic? If your bandwidth is tight, please let me know and a Council member can take ownership of this step. (Your previous blog post was highly effective, but this new notice only needs to be a brief link to the draft and the Discussion thread).
@bookwar wrote in #558 (comment):
+1 @bookwar. Thank you, @humaton and the Forge team, for driving this. Writing policy is tedious, but establishing clear rules now will avoid or reduce major friction later as Forgejo usage scales up.
@siosm wrote in #558 (comment):
Regarding the archiving timeline: Instead of a flat 6-month timestamp, what if we tied inactivity directly to the Fedora release cycle? If a repository shows zero activity for the entire lifespan of a currently supported Fedora Linux release (approximately 13 months), we flag it for archiving. This aligns repository maintenance directly with our OS support windows.
Let me know if you think this overcomplicates the automation logic.
I had time for a formal review pass. I organized my feedback into a few minor copyedits and two broader policy questions for us to weigh in on.
Minor Copyedits & Links
The Forge team link should point directly to the new organization issue template.
Typos & Broken Links: Fix
perform-anttoperformant, and update the incorrect link for the Runner Registration Docs.It might help to provide a couple of clear examples here (e.g.,
a "tickets" repo for planning or "docs" for a Fedora Docs site).The Matrix channel link should be corrected to
#admin:fedoraproject.org.Open Question 1: FPCA and Forge Access
Since ticket #410 is still open and the FPCA remains our current governing policy, should the Forge usage policy explicitly note this default licensing requirement? We might even consider requiring an FPCA signature just to authenticate into Forge. This could serve as a safe bridge while we figure out the long-term implicit consent model, though we should carefully weigh this against any extra friction it might create for new contributors.
Open Question 2: API Usage & Infrastructure Health
The current rule requiring user-agent strings for API usage is great. However, should we also establish a boundary around heavy, automated API scraping—specifically regarding mass data ingestion for LLM training? While we may eventually want to encourage responsible, community-sanctioned AI training on our public platforms, our immediate priority needs to be protecting the Forge infrastructure from being overwhelmed by uncoordinated scraping. Adding a clause focused purely on abuse prevention and infrastructure health might be a smart safeguard.
This just fell off my radar, I updated the wiki page with your suggestions, I think this whole effort about usage policy should be owned by somebody else than Individual Contributor as myself. Can Council take this? The wiki is a git repository with a MarkDownfile.
@humaton, thank you for coming back to update the draft, and I hear the ask to have someone other than an Individual Contributor own this going forward. I reviewed the current wiki draft against my March feedback. The Organizations link, the "performant" typo, and the Matrix channel link are all fixed. The Runner Registration Docs link is still generic rather than pointing to actual registration steps, and the two open policy questions I raised, on FPCA/Forge authentication and on scoping API/scraping limits for things like LLM training, don't look like they've been explicitly resolved yet, though the general abuse language partially covers the second one.
Stepping back, I think this reads more like Terms and Conditions than a typical Council policy, and I want the Council's input on the right path forward. Should this go to Red Hat Legal for inclusion under docs.fedoraproject.org/en-US/legal/, or is it sufficient to adopt as a Council policy through our usual Policy Change Process?
If we're ready to send this to Legal, I'm happy to be the ambassador for that. If it's not ready yet, or if the Council would rather run this through a formal Council vote, I'll need some help executing that, specifically getting the outstanding items above resolved and someone driving the actual review with Council.
Assisted-by: Claude Sonnet 5 (1M context)
@bookwar wrote in #558 (comment):
I think any archiving process is unecessary. It's totally OK for infra repos to remain inactive for months or years. Any kind of automated archiving process seems like a wrong thing.
@zbyszek wrote in #558 (comment):
Thinking about it more, I wonder if it makes sense to say no activity for 12 months or more (i.e., the same timeline of support we offer for Fedora releases), the Fedora Infrastructure Team may send a "keepalive" notice to the organization maintainers or repo maintainers to confirm that the repo still holds value or use.
I could see this making a bigger difference for a repo with huge files and assets added, versus a repository which is primarily issue data. We should be careful about purging things since a repo might not have any activity but may have useful historical context.
How so? By "archiving" a repository, all current content is just frozen as read-only, no actual content is removed. This should not result in any (relevant) storage savings. And since users can just un-archive repositories themselves (unless that functionality is patched out of our forgejo fork), I don't really see any actual need to archive "stale" repositories in the first place ...
Should I be considering not hosting anything on Fedora Forge? These policies are fairly punitive. I don't think I'd be very comfortable with this for the SIG organizations I run. Low activity projects are kind of common for SIG organizations...
What is the cost to the project if we dont mandate an archival process after a period of inactivity on a repo? Costs in this instance mean effort for infra or resources. Are we capped at a certain point to need to have this?
The only things archiving really does is to allow you to sort it differently, and it will disallow changes to it.
I don't think we need to mandate anything like that, we should let orgs decide when to archive things.
I've got one significant concern. Remixes are not explicitly covered in the text as a type of community work.
Fedora remix is a secondary trademark controlled under the trademark policy and as such there should be a place in the forge for community organization of some remixes.
Example 1: currently the Risc 5 effort exists as a remix because there are still outstanding upstreaming kernel modules being worked on. But the intent is that effort will be the base of a new secondary arch work in fedora. That group should be able to have access to forge resources now while they are working as a remix in preparation for the transition. This is an example of a remix that is meant to be temporary and folded back into the project once the technical deviations are no longer necessary. But it may need to continue to exist for future hardware enablement purposes.
Example 2: Fedora Asahi Remix... which is a remix with known technical deviations, keeping it from being an official fedora release, but also has a specific trademark policy grant from Council. It should have access to fedora forge resources. This is an example of a remix that is long lived, because there are irreducible technical deviations with with intention to keep the deviations to a minimum.
Both are examples of remixes that are highly aligned with the Fedora project that Fedora community members are working on that benefit the project long term, even though the technical outputs are such that they must remain remixes. Theses efforts should have access to the forge as a resource.
There needs to be policy concerning remix use of the forge resources. I doubt we'd collectively agree that all remixes should be given access, but there are surely highly aligned remixes that can be considered strategic project partners and can be given access to forge resources on those grounds.
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.
Well, it's not as clear cut to me at least there, but I think it's just terminology... the riscv-sig is a fedora sig and indeed has space on forge.fedoraproject.org. They do a bunch of things, one of which is to make a remix. I agree that they should be allowed/given space in this policy to be in forge.fedoraproject.org as long as the content on the forge is opensource/distributable. This could indeed be clarified.
Folks I'd like to get this policy closed out this week if possible. The only sticking point was around the possible automatic retiring of inactive repos after 12 months. From the council chat room on matrix, @jednorozec proposed this solution (which I paraphrased):
Mandate every org to have a tickets repository allows us to drop the archiving requirement. It gives infra a public way to contact org owner(s) if there has been no activity in a long time. And while email addresses of org owners can be gleaned from FAS, as correctly pointed out by @jednorozec , this way keeps information siloed in individual inboxes.
To now use @jednorozec 's exact words: Establishing a unified, public space for each project group creates better order and visibility. We don't need to mandate how groups track their daily work, but having a single, centralized channel ensures that any contributor can easily reach them while creating a public, linkable record. Because there will be clear place to contact org owners and talk about anything. - and I think this is an excellent compromise that will allow us move forward with publishing the usage policy through the policy change policy process.
I am +1 to the proposal to mandate that every org to have a tickets repository as a clear place and way to contact org owners if a repo has been inactive for a significant period of time.
That's kind of crazy since there's already a mandatory unified way to contact everyone: the fas group email address.
I do agree with Tomas's point though that its easy to silo comms in email inboxes. And, from personal experience, I can miss emails sometimes. This is an acceptable and fine compromise to me to request org owners have a ticket repo rather than having an automatic archiving process.
This archiving repos process is seeming to me like a solution looking for a problem.
@amoloney wrote in #558 (comment):
+1
I do think this invites more questions than answers, like what the best practices are for a tickets repository and how to manage it. But I guess this is an acceptable condition for any new org getting set up on Fedora Forge, that you, the SIG/WG/team lead(s), have to figure it out.
Also, it goes without saying, but I believe we are also voting on the function of a tickets repo, not that the repo is necessarily named "tickets". I have suggested this to a few Fedora teams already, such as the EPEL Steering Committee, and my proposal for renaming the existing repo was voted down.
@gotmax23 wrote in #558 (comment):
Personally, I agree. It makes more sense to me to define more clearly what inappropriate use is, and how actions will be taken for inappropriate/egregious abuse of shared resources.
The challenge here is that someone needs to write such policy. I guess better to not let perfection be the enemy of progress, and there are no rules that say we cannot amend or update the policy later if we discover that we got some important detail wrong.
Not having the archiving clause in the policy does not mean Fedora Infra does not have a possibility or a right to archive something. It means it will not have a defined trigger for this process, and it means that users of the Forge do not have the correct expectation about their repositories under Fedora umbrella.
By putting the expectation in writing we make sure that users of the Forge know what service they are getting. By not putting anything we will let be surprising users later.
I think we need the archiving clause.
But on top of that I am starting to think that maybe we also need a generic clause that the Fedora Project can change the hosting rules with some promised notice period (3-6 months) to ensure that the projects which wouldn't fit in new rules have enough time to migrate.
Yes, it is unlikely that we do another migration or change soon, and we are more or less safe, but no one knows what the future holds for us, and 10 years from now such a clause in the policy would be a good argument against some vibe-coded management decisions shutting down community services overnight.
@amoloney wrote in #558 (comment):
I'm also +1 to the proposal to having a tickets repo, and I'm +1 to accepting the rest of the proposal.
@bookwar wrote in #558 (comment):
I also agree we need some kind of codified process so people know what to expect, plus a clear notification process of changes. It's a large project with a lot of moving parts and a lot of different people involved; writing it down makes sure that, if someone disagrees with a decision, there's a transparent process to follow both for the original decision-maker and for the people afterward who have to decide why something happened.
I'm still -1 on having an automated, time-based archival based on inactivity. We already have inactivity checks for users that removes them from various FAS groups. Archiving those user's private repositories (i.e. forks) would be fine IMO.
But if there's going to be a similar "liveness" check for groups every X months / X/6 Fedora releases, then that should definitely be discussed separately, and much more publicly, since it would be a policy change that would affect more than just the forge instance.
Somehow I am -1 on "an automated, time-based archival based on inactivity". But I am +1 for "the right to archive after inactivity, assuming common sense is applied".
But I guess I should stop insisting if no one else in this thread, including Fedora Infra folks, actually finds this important.
Well, I agree with you FWIW.
@kevin wrote in #558 (comment):
Archiving & un-archiving repos should be easy (an infra ticket) so I'm fine both ways (we let the Fedora Infra team take those decisions when requested or we setup auto-archiving).
Current text says:
I would remove the "automated" part to ease the concerns.
kevin wrote in #558 (comment):
Right, it's unclear what archiving things in Forgejo will actually accomplish to save resources; it just makes it so nobody can contribute to the repository and adds an archived label to repo listings.
The point is not to save the storage resources, imho. The main need for archiving is to not confuse potential contributors, when it is known that the repository is dead and there is no maintainer available.
It is demotivating to spend time on reading some docs repo and trying to make a fix, and then learning that this is actually not the right repo, and the right repo for these docs is now in some very different place and with a different layout.
The example scenario how I would imagine the right to archive to be used:
A drive-by contributor finds a repo and makes a PR to it.
No one replies for a long time.
The contributor comes to Fedora Infra admins and says - can someone with the power merge my very important PR.
The Fedora admin looks and sees that the repo is actually not being used for a long time, because the project was deprecated and replaced.
They say - "sorry, that's a dead repo left after the tool was deprecated and the owner forgot to mark it as such, let me archive it so no one is confused again."
Automation, if it ever added, would be a different story and could be discussed as a separate topic.
I think that's a valid point, but I agree with Fabio that this would be best handled separate from the Forge usage policy. We can have a different policy for inactive groups/SIGs/WGs that prescribes archiving git repos in addition to other group resources (e.g., mailing lists or Matrix rooms) that are dormant.
I'd say that management of repos in organizations owned by an active group should be left up to the group's owners team. Perhaps the policy can explicitly state the Forge organization owners are responsible for archiving repos that are dormant or unmaintained in their respective orgs.
Following the agreement reached in yesterdays council meeting[1], the policy has now been edited to reflect the change to the archiving section and has been published to the various platforms required in the policy change policy process[2][3][4].
I am officially requesting this document be voted on after 13 August, 2026, provided there are no significant edits to be made based on any feedback received. This vote will require full council consensus to ratify the policy.
During these next two weeks, please keep an eye on this discussion, and I will be periodically reviewing it for any potential changes to the document that may require us to extend the feedback period ahead of the proposed deadline.
[1] https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-07-29/fedora-council-bi-weekly-meeting.2026-07-29-14.00.html
[2] https://docs.fedoraproject.org/en-US/council/policy/policy-change-policy/
[3] https://discussion.fedoraproject.org/t/policy-proposal-fedora-forge-usage-policy/198024
[4] https://communityblog.fedoraproject.org/fedora-forge-usage-policy/