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
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
6 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.