Policy Proposal: Fedora Forge Usage Policy

Project Discussion
1

After extensive review and discussion on the ticket request and in recent council meetings (see meetbot for 29 July and 15 July), the Fedora Council would like to initiate the policy change policy process for ratifying the Fedora Forge Usage policy. This document is open to public feedback (if any) for a minimum of two weeks. If there are no significant changes to be made to the policy based on community feedback after Thursday, 13 August 2026, this policy will go to a formal ticket vote for Council to approve or reject.
If there are significant changes to be made to the document, Council will review the policy and, if necessary, extend the feedback period before calling for an official vote. Please use this post for providing feedback.

The policy can be found on the Council wiki page in Fedora Forge, published on the Community Blog and pasted below here for convenience.

Thank you everyone for your contributions to this policy so far, and on behalf of the Council, we look forward to working with you all to ratify this policy soon.

Table of Contents

Fedora Forge Usage Policy

Welcome to the Fedora Forge. This Forgejo instance is provided by the Fedora Infrastructure team to support the daily operations, development, and collaboration of the Fedora Project.

To ensure this service remains reliable, secure, and useful for everyone in the Fedora community, all users must adhere to the following usage policy.

1. Scope, Criteria, and Exceptions

The Fedora Forge is a dedicated workspace for the Fedora Project. Historically, the Fedora Project utilized pagure.io, which operated as a general-use public forge where Fedora repositories coexisted alongside personal projects, unrelated upstream software, and individual portfolios.

The Fedora Forge (powered by Forgejo) intentionally adopts a narrower scope. It is not a public, general-use Git hosting provider. It is an internal piece of project infrastructure, explicitly provisioned to host the code, documentation, and tooling that directly build, manage, and govern the Fedora Project.

Criteria for “Fedora Project Related”

To qualify for hosting on the Fedora Forge, a repository must meet at least one of the following criteria:

  • Infrastructure and Operations: Configuration management, deployment scripts, or tooling used by the Fedora Infrastructure team to run the project.
  • Release Engineering and Packaging: Tools, scripts, and templates used to build, compose, and distribute Fedora releases, editions, and spins.
  • Governance and Team Organization: Trackers, documentation, and collaborative spaces for official Fedora Teams, Special Interest Groups (SIGs), Working Groups, and Fedora Council initiatives.
  • Fedora-Specific Software: Software projects conceptualized and developed primarily to serve the Fedora community (e.g., Fedora Badges, Bodhi, fedmsg).

Exceptions and Special Cases (Ecosystem Upstreams)

While general upstream development should happen on public forges (like GitHub, GitLab, or Codeberg), the Fedora Project recognizes that certain large-scale upstream projects are so deeply intertwined with Fedora’s infrastructure and history that they qualify as exceptions.

Recognized Exceptions:

  • Foundational infrastructure tools heavily maintained by Fedora and Red Hat ecosystem contributors (e.g., Koji, FreeIPA).
  • Core system components where the primary development team is historically rooted in the Fedora community and relies on Fedora Infrastructure for their workflow.

Note: Being packaged in the Fedora repository does not automatically grant a project exception status to use the Fedora Forge as its upstream host.

Decision Process for Edge Cases

If a community member is unsure whether their project fits the scope or qualifies as an ecosystem exception, the following process applies:

  1. Request Submission: The requester must open a ticket on the Fedora Infrastructure tracker, detailing the project’s purpose, its connection to Fedora, and why it should be hosted on the Fedora Forge rather than a public alternative.
  2. Infrastructure Review: The Fedora Infrastructure team will conduct an initial review against the established criteria to assess technical feasibility and resource impact.
  3. Steering Committee Consultation: If the request falls into a gray area, the Infrastructure team will escalate the ticket to the Fedora Engineering Steering Committee (FESCo) or the Fedora Council for a policy ruling.
  4. Final Resolution: The decision will be documented in the ticket. If denied, the requester will be encouraged to host the project on a public forge and mirror specific components if strictly required for internal Fedora builds.

2. Access and Authentication

Access to the Fedora Forge is integrated with our central identity systems to ensure secure and accountable access.

  • Account Creation and Login: All authentication is handled via the Fedora Account System (FAS). You cannot create a local account directly on the Forgejo instance. To log in, use the Single Sign-On (SSO) integration with your active FAS credentials.
  • Personal Namespaces: Upon your first login, a personal namespace (e.g., Making sure you're not a bot!) is automatically provisioned for you. You can only fork repositories into this space, creation of new repositories is allowed only under Organization.
  • Organizations and Teams: To prevent organizational sprawl, the creation of top-level Organizations (e.g., /infra or /quality) is restricted. If your Fedora team or SIG needs a dedicated Organization space, please open a ticket with the Forge team. Organization owners are responsible for managing team access within their assigned space.
  • Account Deactivation: If your FAS account is suspended, disabled, or marked as inactive, your access to the Fedora Forge will be automatically revoked. Repositories hosted in your personal namespace may be archived or removed if your account remains inactive for an extended period. If you are leaving the project, please transfer ownership of any critical tools to a Fedora Organization or an active co-maintainer before your departure.

3. Code of Conduct and Community Behavior

The Fedora Forge is a collaborative space. All activity on this platform is strictly governed by the Fedora Code of Conduct.

4. Prohibited Activities

To ensure the Fedora Forge remains performant, secure, and legally compliant, the following activities and content are strictly prohibited:

  • Non-Fedora Projects: As stated in the scope, this Forge is not a general-purpose Git host. Personal portfolios, dotfiles, or hobby projects not directly tied to Fedora are prohibited.
  • Malicious Content: Hosting malware, exploits, botnet command-and-control infrastructure, or phishing materials. (Note: Security-related tools strictly used for Fedora infrastructure testing must be explicitly approved).
  • Proprietary and Copyrighted Material: Uploading copyrighted materials you do not have the right to distribute, or hosting proprietary, closed-source binary blobs. All code should be open source and compliant with Fedora’s licensing guidelines.
  • Exposing Secrets: Committing sensitive information such as passwords, API tokens, private SSH keys, or Personally Identifiable Information (PII).
  • System Abuse: Engaging in activities that degrade the performance of the Forgejo instance or its runners, such as aggressive network scraping, DDoS attacks, or intentionally triggering infinite CI loops.
  • Cryptocurrency Mining: Using the Forge or its CI/CD runners to mine cryptocurrency is strictly forbidden and will result in an immediate, permanent ban.

5. Resource Limits and CI/CD

We want to empower Fedora teams with the tools they need, but we must also manage our infrastructure costs and storage effectively.

  • Repository Size: Git is not a backup system. Please keep repositories focused on source code and text-based documentation.

    • Repositories should ideally remain under 500MB.
    • If your project requires large assets (e.g., design files, test datasets), you must use Git LFS (Large File Storage).

  • Forgejo Actions and CI Runners:

    • Shared Infrastructure: The default CI runners provided by Fedora Infrastructure are a shared community resource. Jobs should be optimized to run efficiently and are subject to a maximum timeout of 10 minutes per job.

    • Community-Owned Runners (Bring Your Own): We highly encourage larger teams, SIGs, and Working Groups with extensive testing or specific architectural requirements (e.g., heavily utilizing ARM, RISCV, or requiring long build times) to provision and register their own runners. Dedicated runners can be attached directly to your Organization or specific repositories.

    • Compliance for Custom Runners: Even if your team provides the compute resources, any runner connected to the Fedora Forge is an extension of our infrastructure. All workflows and actions executed on community-owned runners must strictly comply with Section 4 (Prohibited Activities). You may not use custom runners to bypass policy (e.g., no cryptocurrency mining, no building unrelated non-Fedora upstream projects, and no malicious network scraping).

    • Registration Process: To register a dedicated runner for your team, please review our Runner Registration Docs and ensure your runner is secured according to Fedora Infrastructure standards.

  • API Usage: Automated scripts and bots interacting with the Forgejo API must respect rate limits and include descriptive user-agent strings identifying the tool and its maintainer.

6. Repository Lifecycle and Organization

  • Naming Conventions: We have a general naming convention, there should be tickets repository in your Organisation to have a single point of opening tickets relevant to your group. The docs repo in you organization should point to your groups official sources for docs.fedoraproject.org namespace. In other cases please use clear, descriptive names for repositories so other community members can easily understand their purpose.
  • Archiving: Projects that are no longer actively maintained should be archived (marked as read-only) to signal their status to the community. Active Forge organization owners should archive repos as necessary. If needed (e.g., in the case of an inactive organization), the Infrastructure team reserves the right to archive repositories that have seen no activity after trying to contact the organization owners.**.
  • Deletion: If you need an Organization or repository completely deleted, please open a ticket with the Forge team. The Infrastructure team also reserves the right to delete abandoned, non-compliant, or empty repositories to maintain a clean workspace.

7. Support and Abuse Reporting

  • Getting Help: For technical issues with the Fedora Forge (e.g., CI runner failures, login issues, requesting an Organization), please open a ticket on the Forge team tracker or ask in the #fedora-admin Matrix channel.
  • Reporting Code of Conduct Violations: To report a CoC violation occurring on the Forge, please contact the Fedora Code of Conduct Committee.
  • Reporting Security/Legal Issues: To report a security vulnerability on the platform, exposed secrets, or a DMCA/copyright violation, please immediately send an email to Fedora Infrastructure team.
1 Like
2

How? They were not allowed to have an org on the Forge. What is the purpose of this part of the policy? Do we have some specific examples in mind?

1 Like
3

I think we should give some guidance on what “large”. For example, council-docs is IMHO large (300 Mo) for what it is, and that’s because there is a 245M pdf in ./project/modules/ROOT/assets/attachments/brand-book-revised-2024.pdf. It should be placed in git LFS, but it isn’t. Same goes for the badges repo, with gigantic STL files for 3D printed badges, etc.

Wouldn’t that formulation prevent hosting the linux kernel or any firmware for that matter, cause they are closed source and proprietary ? I agree with the sentiment, but I think something closer to “we can’t host anything that wouldn’t be accepted as a Fedora packages” be a more coherent policy.

The way I understand this is that any repo with name of people would be off limit, because a name is PII. So council docs, where we can read the names of council members would have to be removed with that policy.

I also wonder if encrypted secret are allowed or not. While my team do not use Fedora forge for our repos, we have encrypted secrets in our ansible repo , and I think others might too. (we also have encrypted PII in the form of email, but mostly for spam prevention).

The policy also specifically say “committing”, but I assume this would also cover tickets. And this also bring the question of private tickets (once that’s done). In the past, we used tickets for handling shipping of goods to ambassadors, so there was a private repo with private tickets and people address.

I think there is some discussions in OSPO around the constraint of the CRA and stuff like this, so maybe a dedicated separate email would be better. I will point my coworkers to the policy, and I think @kevin is aware of that.

Also, what about Centos related projects, do they count as “Fedora” (given the overlap between the 2 projects) ?

2 Likes
4

How is it decided which of the two bodies makes this decision?

EDIT: Discourse completely removes quoted sections when replying via email :frowning: . This was in response to 3. in the Decision Process for Edge Cases section.

5

…snip…

Recognized Exceptions:

  • Foundational infrastructure tools heavily maintained by Fedora and Red Hat ecosystem contributors (e.g., Koji, FreeIPA).
  • Core system components where the primary development team is historically rooted in the Fedora community and relies on Fedora Infrastructure for their workflow.

Perhaps it would be nice to refer to some document/git repo here to
avoid having to change this policy everytime there is a new exception?

ie, ‘The list of current approved exceptions can be seen at …’

Note: Being packaged in the Fedora repository does not automatically grant a project exception status to use the Fedora Forge as its upstream host.

Decision Process for Edge Cases

If a community member is unsure whether their project fits the scope or qualifies as an ecosystem exception, the following process applies:

  1. Request Submission: The requester must open a ticket on the Fedora Infrastructure tracker, detailing the project’s purpose, its connection to Fedora, and why it should be hosted on the Fedora Forge rather than a public alternative.
  2. Infrastructure Review: The Fedora Infrastructure team will conduct an initial review against the established criteria to assess technical feasibility and resource impact.
  3. Steering Committee Consultation: If the request falls into a gray area, the Infrastructure team will escalate the ticket to the Fedora Engineering Steering Committee (FESCo) or the Fedora Council for a policy ruling.

Might make more sense to say ‘FESCO’ and allow for a Council escalation
from there? To avoid someone asking both groups at the same time?

  1. Final Resolution: The decision will be documented in the ticket. If denied, the requester will be encouraged to host the project on a public forge and mirror specific components if strictly required for internal Fedora builds.

I think longer term this is fine, but currently forge setup requests
have been filed in the forge project. Probibly fine to leave it as is
longer term.

…snip…

5. Resource Limits and CI/CD

We want to empower Fedora teams with the tools they need, but we must also manage our infrastructure costs and storage effectively.

  • Repository Size: Git is not a backup system. Please keep repositories focused on source code and text-based documentation.

    • Repositories should ideally remain under 500MB.
    • If your project requires large assets (e.g., design files, test datasets), you must use Git LFS (Large File Storage).

Is there any documentation on this? and what is large? :slight_smile:

Thanks.

1 Like
6

Fedora Forge Usage Policy

Welcome to the Fedora Forge. This Forgejo instance is provided by the Fedora Infrastructure team to support the daily operations, development, and collaboration of the Fedora Project.

To ensure this service remains reliable, secure, and useful for everyone in the Fedora community, all users must adhere to the following usage policy.

1. Scope, Criteria, and Exceptions

The Fedora Forge is a dedicated workspace for the Fedora Project. Historically, the Fedora Project utilized pagure.io, which operated as a general-use public forge where Fedora repositories coexisted alongside personal projects, unrelated upstream software, and individual portfolios.

The Fedora Forge (powered by Forgejo) intentionally adopts a narrower scope. It is not a public, general-use Git hosting provider. It is an internal piece of project infrastructure, explicitly provisioned to host the code, documentation, and tooling that directly build, manage, and govern the Fedora Project.

Criteria for “Fedora Project Related”

To qualify for hosting on the Fedora Forge, a repository must meet at least one of the following criteria:

  • Infrastructure and Operations: Configuration management, deployment scripts, or tooling used by the Fedora Infrastructure team to run the project.
  • Release Engineering and Packaging: Tools, scripts, and templates used to build, compose, and distribute Fedora releases, editions, and spins.
  • Governance and Team Organization: Trackers, documentation, and collaborative spaces for official Fedora Teams, Special Interest Groups (SIGs), Working Groups, and Fedora Council initiatives.
  • Fedora-Specific Software: Software projects conceptualized and developed primarily to serve the Fedora community (e.g., Fedora Badges, Bodhi, fedmsg).

Exceptions and Special Cases (Ecosystem Upstreams)

While general upstream development should happen on public forges (like GitHub, GitLab, or Codeberg), the Fedora Project recognizes that certain large-scale upstream projects are so deeply intertwined with Fedora’s infrastructure and history that they qualify as exceptions. The list of current approved exceptions can be seen at <link to doc/repo>.

Note: Being packaged in the Fedora repository does not automatically grant a project exception status to use the Fedora Forge as its upstream host.

Decision Process for Edge Cases

If a community member is unsure whether their project fits the scope or qualifies as an ecosystem exception, the following process applies:

  1. Request Submission: The requester must open a ticket on the Fedora Infrastructure tracker, detailing the project’s purpose, its connection to Fedora, and why it should be hosted on the Fedora Forge rather than a public alternative.
  2. Infrastructure Review: The Fedora Infrastructure team will conduct an initial review against the established criteria to assess technical feasibility and resource impact.
  3. Steering Committee Consultation: If the request falls into a gray area, the Infrastructure team will escalate the ticket to the Fedora Engineering Steering Committee (FESCo) for a policy ruling, or Fedora Council in the event of an escalation
  4. Final Resolution: The decision will be documented in the ticket. If denied, the requester will be encouraged to host the project on a public forge and mirror specific components if strictly required for internal Fedora builds.

2. Access and Authentication

Access to the Fedora Forge is integrated with our central identity systems to ensure secure and accountable access.

  • Account Creation and Login: All authentication is handled via the Fedora Account System (FAS). You cannot create a local account directly on the Forgejo instance. To log in, use the Single Sign-On (SSO) integration with your active FAS credentials.
  • Personal Namespaces: Upon your first login, a personal namespace (e.g., Making sure you're not a bot! ) is automatically provisioned for you. You can only fork repositories into this space, creation of new repositories is allowed only under Organization.
  • Organizations and Teams: To prevent organizational sprawl, the creation of top-level Organizations (e.g., /infra or /quality) is restricted. If your Fedora team or SIG needs a dedicated Organization space, please open a ticket with the Forge team. Organization owners are responsible for managing team access within their assigned space.
  • Account Deactivation: If your FAS account is suspended, disabled, or marked as inactive, your access to the Fedora Forge will be automatically revoked. Repositories hosted in your personal namespace may be archived or removed if your account remains inactive for an extended period. If you are leaving the project, please transfer ownership of any critical tools to a Fedora Organization or an active co-maintainer before your departure.

3. Code of Conduct and Community Behavior

The Fedora Forge is a collaborative space. All activity on this platform is strictly governed by the Fedora Code of Conduct.

4. Prohibited Activities

To ensure the Fedora Forge remains performant, secure, and legally compliant, the following activities and content are strictly prohibited:

  • Non-Fedora Projects: As stated in the scope, this Forge is not a general-purpose Git host. Personal portfolios, dotfiles, or hobby projects not directly tied to Fedora are prohibited.

  • Malicious Content: Hosting malware, exploits, botnet command-and-control infrastructure, or phishing materials. (Note: Security-related tools strictly used for Fedora infrastructure testing must be explicitly approved).

  • Proprietary and Copyrighted Material: Uploading copyrighted materials you do not have the right to distribute, or hosting proprietary, closed-source binary blobs. All code should be open source and compliant with Fedora’s licensing guidelines.

  • Exposing Secrets: Committing sensitive information such as passwords, API tokens, private SSH keys, or Personally Identifiable Information (PII).*

  • System Abuse: Engaging in activities that degrade the performance of the Forgejo instance or its runners, such as aggressive network scraping, DDoS attacks, or intentionally triggering infinite CI loops.

  • Cryptocurrency Mining: Using the Forge or its CI/CD runners to mine cryptocurrency is strictly forbidden and will result in an immediate, permanent ban.

*Names of community members in governance seats are the sole exception to where PII may be shared.

5. Resource Limits and CI/CD

We want to empower Fedora teams with the tools they need, but we must also manage our infrastructure costs and storage effectively.

  • Repository Size: Git is not a backup system. Please keep repositories focused on source code and text-based documentation.

    • Repositories should ideally remain under 500MB. If your project requires larger assets (e.g., design files, test datasets), please consider using Git LFS (Large File Storage).

  • Forgejo Actions and CI Runners:

    • Shared Infrastructure: The default CI runners provided by Fedora Infrastructure are a shared community resource. Jobs should be optimized to run efficiently and are subject to a maximum timeout of 10 minutes per job.

    • Community-Owned Runners (Bring Your Own): We highly encourage larger teams, SIGs, and Working Groups with extensive testing or specific architectural requirements (e.g., heavily utilizing ARM, RISCV, or requiring long build times) to provision and register their own runners. Dedicated runners can be attached directly to your Organization or specific repositories.

    • Compliance for Custom Runners: Even if your team provides the compute resources, any runner connected to the Fedora Forge is an extension of our infrastructure. All workflows and actions executed on community-owned runners must strictly comply with Section 4 (Prohibited Activities). You may not use custom runners to bypass policy (e.g., no cryptocurrency mining, no building unrelated non-Fedora upstream projects, and no malicious network scraping).

    • Registration Process: To register a dedicated runner for your team, please review our Runner Registration Docs and ensure your runner is secured according to Fedora Infrastructure standards.

  • API Usage: Automated scripts and bots interacting with the Forgejo API must respect rate limits and include descriptive user-agent strings identifying the tool and its maintainer.

6. Repository Lifecycle and Organization

  • Naming Conventions: We have a general naming convention, there should be tickets repository in your Organisation to have a single point of opening tickets relevant to your group. The docs repo in you organization should point to your groups official sources for docs.fedoraproject.org namespace. In other cases please use clear, descriptive names for repositories so other community members can easily understand their purpose.
  • Archiving: Projects that are no longer actively maintained should be archived (marked as read-only) to signal their status to the community. Active Forge organization owners should archive repos as necessary. If needed (e.g., in the case of an inactive organization), the Infrastructure team reserves the right to archive repositories that have seen no activity after trying to contact the organization owners.**.
  • Deletion: If you need an Organization or repository completely deleted, please open a ticket with the Forge team. The Infrastructure team also reserves the right to delete abandoned, non-compliant, or empty repositories to maintain a clean workspace.

7. Support and Abuse Reporting

  • Getting Help: For technical issues with the Fedora Forge (e.g., CI runner failures, login issues, requesting an Organization), please open a ticket on the Forge team tracker or ask in the #fedora-admin Matrix channel.
  • Reporting Code of Conduct Violations: To report a CoC violation occurring on the Forge, please contact the Fedora Code of Conduct Committee.
  • Reporting Security/Legal Issues: To report a security vulnerability on the platform, exposed secrets, or a DMCA/copyright violation, please immediately send an email to Fedora Infrastructure team.
7

^^ This is a full redraft with edits to include feedback received so far. The amendments are in bold italics.

@churchyard - I dont understand your question enough to create an edit or answer to it. Its just not my forte :slight_smile: so patch welcome if you have a suggestion on rewording or just to drop that sentence altogether.

Thank you very much all for taking the time to read though and give feedback on this, its highly appreciated.

1 Like
8

Thanks for the update! A couple more nits are below :slight_smile:

I don’t think the bolded part is needed. FESCo not being able to decide on something/needing Council escalation is a matter of general governance policy, not something specific to Forge requests.

I think we can remove this sentence entirely. I don’t think there’s any strong reason to mirror repositories if the project is not appropriate for Fedora Forge hosting in the first place.

I don’t think the policy should specify timeouts or limits. I think that’s up to the Fedora Forge team and also is set differently for different types of runners (podman, testing-farm, etc.) AFAIK. Can we remove “and are subject …” altogether or replace it with a general statement that the Forge team “may impose reasonable limits on CI usage”?

This section looks good now. Thanks.

Can we replace “reserves the right” with “may” (in both places that it’s used) so this sounds less legalistic?

2 Likes
9

Im +1 to:

  • Removing ‘or Fedora Council in the event of an escalation’

  • Removing ‘If denied, the requester will be encouraged to host the project on a public forge and mirror specific components if strictly required for internal Fedora builds.’

Below then are suggested edits to CI jobs and Archiving sections:

  • Please ensure jobs are optimized to run efficiently. The Forge team may impose reasonable limits on CI usage for jobs that have longer timeouts.

  • If needed (e.g., in the case of an inactive organization), the Infrastructure team may archive repositories that have seen no activity after trying to contact the organization owners.

Ill wait a few more days for any other suggested edits before republishing v.3 of the draft. Thank you all again :slight_smile:

10

I think this need to be changed, because there is PII everywhere:

  • names that we can find in spec files (eg, the old %changelog)
  • names that we can find in patches
  • names that we find in git log
  • copyright notices

I think we can’t really remove theses as it would be a DMCA violation (17 U.S. Code § 1202).

But we also have names used around in repo. For example, there is interns on the first repo of the first org of the forge.

Or this one with the whole release team names published (since the docs are in git). I randomly picked repos, this is not exhaustive.

Since a email would also count as PII if it go to a single person (this is personal, it identify a person, and that’s a information), so there is also another repo with contact emails, while these likely do no count as “governance seats”.

And there is also some cases where “governance seats” is unclear. For example, does this list of officers count as governance seats ?

There is also the case of historical data that we will import, as I am sure that some older flock website and/or prospectus have Dorka phone’s numbers somewhere. I am not sure we want to rewrite history to remove them.

1 Like
11

Yeah, I agree @misc , that information is everywhere. Should we just remove the mention of PII from that paragraph altogether?

12

No, I do not think this should be removed. The policy itself is a good idea, but we have the reality of being open to deal with.

Maybe this could be replaced by something along “do not publish/commit PII about another person without their permissions if this wasn’t public before and if this is not needed” or something like that ?

People can publish their own information (so this cover git log), they can commit public copyright info from public opensource code (so cover patches). And I assume that people whose name is already public/published in the past are ok with that (so old data, existing name for non officers).

And the only problem I see (for now) with this formulation is the risk of harassement (eg, deadnaming someone on purpose because they were known under another name that was public), but that’s covered by the CoC.

13

That’s maybe not in the scope of the policy, but since the forge is going to be archived by Software Heritage (or so I hope), shouldn’t it be mentioned ?

It seems the infra team use a specific different email for infra security, cf their doc. DMCA/copyright is also on its own page (without email). I think a link to the pages is maybe better to avoid fragmentation even if in practice, everything will go to the right people in the end.

This kinda mandate using English for the description, no ? I am not against it but I wonder what are the practices of local communities, and the impact on moderation.

What would happen if a project is no longer primarily serving the Fedora community ?
For example, another distro start to use yum, then Fedora drop yum for dnf, but the other distro still use yum. I assume they should move, but do we want to make it explicitly written ? What if the other distro is RHEL or Centos ?

14
  • Archiving: Projects that are no longer actively maintained should be archived (marked as read-only) to signal their status to the community

"That’s maybe not in the scope of the policy, but since the forge is going to be archived by Software Heritage (or so I hope), shouldn’t it be mentioned ?

Is it? I will need to verify this with the forge team, but yes there is no harm in stating this.

It seems the infra team use a specific different email for infra security, cf their doc. DMCA/copyright is also on its own page (without email). I think a link to the pages is maybe better to avoid fragmentation even if in practice, everything will go to the right people in the end.

Agreed, I will edit the links to the appropriate pages so theres less confusion.

  • In other cases please use clear, descriptive names for repositories so other community members can easily understand their purpose.

This kinda mandate using English for the description, no ? I am not against it but I wonder what are the practices of local communities, and the impact on moderation.

I am -1 to changing this wording. I dont think this gains us any more clarity.

  • Fedora-Specific Software: Software projects conceptualized and developed primarily to serve the Fedora community (e.g., Fedora Badges, Bodhi, fedmsg).

What would happen if a project is no longer primarily serving the Fedora community ?
For example, another distro start to use yum, then Fedora drop yum for dnf, but the other distro still use yum. I assume they should move, but do we want to make it explicitly written ? What if the other distro is RHEL or Centos ?

This is an interesting corner case! My personal opinion is that the project should reach out to FESCo, and follow the ‘exceptions’ process to request to remain in Fedora Forge. While they might not serve Fedora directly, we should not try to silo ourselves from known projects that are allies or closely associated with the project on an interpersonal level, if not necessarily technical one. If thats an agreeable solution, I propose we add that guidance to the policy.

1 Like
15

Re: PII - the council discussed this at the meeting today. The proposal we agreed to is:

We will edit the Code of Conduct section to include short sentence on PII, along the lines of: ‘Please refer to our docs if publishing PII, or request guidance from the committee if needed’ and remove that mention from the Prohibited Articles section.

I have some more feedback to address from the news and announcements section, and then I will get them all into a v.3 and publish soon.

1 Like
Fedora Forge Usage Policy
16

I’m neutral on adding anything about this. Infra and/or FESCo can re-consider previously approved usages on a case-by-case basis, but I’m not sure that we need to explicitly mention projects “no longer primarily serving the Fedora community” in the policy — It’s a corner case.

1 Like
17

From a quick check, some repositories are archived, but not all, so that’s a case by case basis and unlikely to be a agreement (I know SH ask before overloading servers). I know that some team at RH was looking at Software Heritage to escrow our code for GPL compliance reasons (as Intel did), but it was more than 6 years ago, or in corporate units, 47 reorganisations ago, so I do not know what happened or who is in charge. I assume SH would want to archive Fedora code if only because the project is a important one so maybe we should see with them if not done already.

18

8 posts were split to a new topic: Fedora Forge offtopic

25

@misc I checked with the forge team in matrix on the archiving with software heritage. My, and their understanding is that we don’t use it, but there is a self-service form that the project could submit to Software Heritage if we would like to request that. Maybe that might happen in the future, but as of now it doesn’t seem to be something Fedora will request.

1 Like
26

Below is version 3, which I believe (and hope) it includes all feedback received so far. The intention is to continue with the feedback period of another week, and then reassess this policy’s readiness for a vote from council soon after.

Fedora Forge Usage Policy

Welcome to the Fedora Forge. This Forgejo instance is provided by the Fedora Infrastructure team to support the daily operations, development, and collaboration of the Fedora Project.

To ensure this service remains reliable, secure, and useful for everyone in the Fedora community, all users must adhere to the following usage policy.

1. Scope, Criteria, and Exceptions

The Fedora Forge is a dedicated workspace for the Fedora Project. Historically, the Fedora Project utilized pagure.io, which operated as a general-use public forge where Fedora repositories coexisted alongside personal projects, unrelated upstream software, and individual portfolios.

The Fedora Forge (powered by Forgejo) intentionally adopts a narrower scope. It is not a public, general-use Git hosting provider. It is an internal piece of project infrastructure, explicitly provisioned to host the code, documentation, and tooling that directly build, manage, and govern the Fedora Project.

Criteria for “Fedora Project Related”

To qualify for hosting on the Fedora Forge, a repository must meet at least one of the following criteria:

  • Infrastructure and Operations: Configuration management, deployment scripts, or tooling used by the Fedora Infrastructure team to run the project.

  • Release Engineering and Packaging: Tools, scripts, and templates used to build, compose, and distribute Fedora releases, editions, and spins.

  • Governance and Team Organization: Trackers, documentation, and collaborative spaces for official Fedora Teams, Special Interest Groups (SIGs), Working Groups, and Fedora Council initiatives.

  • Fedora-Specific Software: Software projects conceptualized and developed primarily to serve the Fedora community (e.g., Fedora Badges, Bodhi, fedmsg).

Exceptions and Special Cases (Ecosystem Upstreams and other Edge Cases)

While general upstream development should happen on public forges (like GitHub, GitLab, or Codeberg), the Fedora Project recognizes that certain large-scale upstream projects are so deeply intertwined with Fedora’s infrastructure and history that they qualify as exceptions. We also recognise that there are edge cases that may arise from time to time where adjacent projects (e.g CentOS who share same account infra) may wish to use Fedora Forge. The list of current approved exceptions can be seen at <link to doc/repo>.

Note: Being packaged in the Fedora repository does not automatically grant a project exception status to use the Fedora Forge as its upstream host.

Decision Process for Edge/Special Cases

If a community member is unsure whether their project fits the scope or qualifies as an ecosystem exception, the following process applies:

  1. Request Submission: The requester must open a ticket on the Fedora Infrastructure tracker, detailing the project’s purpose, its connection to Fedora, and why it should be hosted on the Fedora Forge rather than a public alternative.

  2. Infrastructure Review: The Fedora Infrastructure team will conduct an initial review against the established criteria to assess technical feasibility and resource impact.

  3. Steering Committee Consultation: If the request falls into a gray area, the Infrastructure team will escalate the ticket to the Fedora Engineering Steering Committee (FESCo) for a policy ruling.

  4. Final Resolution: The decision will be documented in the ticket. If denied, the requester will be encouraged to host the project on a public forge and mirror specific components if strictly required for internal Fedora builds.

2. Access and Authentication

Access to the Fedora Forge is integrated with our central identity systems to ensure secure and accountable access.

  • Account Creation and Login: All authentication is handled via the Fedora Account System (FAS). You cannot create a local account directly on the Forgejo instance. To log in, use the Single Sign-On (SSO) integration with your active FAS credentials.

  • Personal Namespaces: Upon your first login, a personal namespace (e.g., Making sure you’re not a bot! ) is automatically provisioned for you. You can only fork repositories into this space, creation of new repositories is allowed only under Organization.

  • Organizations and Teams: To prevent organizational sprawl, the creation of top-level Organizations (e.g., /infra or /quality) is restricted. If your Fedora team or SIG needs a dedicated Organization space, please open a ticket with the Forge team. Organization owners are responsible for managing team access within their assigned space.

  • Account Deactivation: If your FAS account is suspended, disabled, or marked as inactive, your access to the Fedora Forge will be automatically revoked. Repositories hosted in your personal namespace may be archived or removed if your account remains inactive for an extended period. If you are leaving the project, please transfer ownership of any critical tools to a Fedora Organization or an active co-maintainer before your departure.

3. Code of Conduct and Community Behavior

The Fedora Forge is a collaborative space. All activity on this platform is strictly governed by the Fedora Code of Conduct. Please refer to our code of conduct guidelines if publishing PII, or request guidance from the committee if needed.

4. Prohibited Activities

To ensure the Fedora Forge remains performant, secure, and legally compliant, the following activities and content are strictly prohibited, and may result in an immediate, permanent ban.

  • Non-Fedora Projects: As stated in the scope, this Forge is not a general-purpose Git host. Personal portfolios, dotfiles, or hobby projects not directly tied to Fedora are prohibited.

  • Malicious Content: Hosting malware, exploits, botnet command-and-control infrastructure, or phishing materials. (Note: Security-related tools strictly used for Fedora infrastructure testing must be explicitly approved).

  • Proprietary and Copyrighted Material: Uploading copyrighted materials you do not have the right to distribute, or hosting proprietary, closed-source binary blobs. All code should be open source and compliant with Fedora’s licensing guidelines.

  • Exposing Secrets: Committing sensitive information such as, but not limited to, passwords, API tokens, or private SSH keys.

  • System Abuse: Engaging in activities that degrade the performance of the Forgejo instance or its runners, such as aggressive network scraping, creating gigantic repositories (see resource limit section), DDoS attacks, or intentionally triggering infinite CI loops.

  • Cryptocurrency Mining: Using the Forge or its CI/CD runners to mine cryptocurrency is strictly forbidden.

5. Resource Limits and CI/CD

We want to empower Fedora teams with the tools they need, but we must also manage our infrastructure costs and storage effectively.

  • Repository Size: Git is not a backup system. Please keep repositories focused on source code and text-based documentation.

    • Repositories should ideally remain under 500MB. If your project requires larger assets (e.g., design files, test datasets), please consider using Git LFS (Large File Storage).

  • **Forgejo Actions and CI Runners:
    **

    • Shared Infrastructure: The default CI runners provided by Fedora Infrastructure are a shared community resource. Jobs should be optimized to run efficiently and are subject to a maximum timeout of 10 minutes per job.

    • Community-Owned Runners (Bring Your Own): We highly encourage larger teams, SIGs, and Working Groups with extensive testing or specific architectural requirements (e.g., heavily utilizing ARM, RISCV, or requiring long build times) to provision and register their own runners. Dedicated runners can be attached directly to your Organization or specific repositories.

    • Compliance for Custom Runners: Even if your team provides the compute resources, any runner connected to the Fedora Forge is an extension of our infrastructure. All workflows and actions executed on community-owned runners must strictly comply with Section 4 (Prohibited Activities). You may not use custom runners to bypass policy (e.g., no cryptocurrency mining, no building unrelated non-Fedora upstream projects, and no malicious network scraping).

    • Registration Process: To register a dedicated runner for your team, please review our Runner Registration Docs and ensure your runner is secured according to Fedora Infrastructure standards.

  • API Usage: Automated scripts and bots interacting with the Forgejo API must respect rate limits and include descriptive user-agent strings identifying the tool and its maintainer.

6. Repository Lifecycle and Organization

  • Naming Conventions: We have a general naming convention, there should be a ticket repository in your Organisation to have a single point of opening tickets relevant to your group. The docs repo in your organization should point to your groups official sources for docs.fedoraproject.org namespace. In other cases please use clear, descriptive names for repositories so other community members can easily understand their purpose.

  • Archiving: Projects that are no longer actively maintained should be archived (marked as read-only) to signal their status to the community. Active Forge organization owners should archive repos as necessary. If needed (e.g., in the case of an inactive organization), the Infrastructure team reserves the right to archive repositories that have seen no activity after trying to contact the organization owners.**.

  • Deletion: If you need an Organization or repository completely deleted, please open a ticket with the Forge team. The Infrastructure team also reserves the right to delete abandoned, non-compliant, or empty repositories to maintain a clean workspace.

7. Support and Abuse Reporting

  • Getting Help: For technical issues with the Fedora Forge (e.g., CI runner failures, login issues, requesting an Organization), please open a ticket on the Forge team tracker or ask in the #fedora-admin Matrix channel.

  • Reporting Code of Conduct Violations: To report a CoC violation occurring on the Forge, please contact the Fedora Code of Conduct Committee.

  • Reporting Security/Legal Issues: To report a security vulnerability on the platform, exposed secrets, or a DMCA/copyright violation, please immediately send an email to Fedora Infrastructure team.