amoloney commented

Owner

Summary

Council members are requested to vote on the proposed Fedora Forge Usage Policy by 30 September, 2026.

Background

The Fedora Forge Usage Policy proposal has been under community review for several weeks following the triggering of the Policy Change Policy. The Fedora Council agreed in the most recent meeting (23 Sept, 2026) that the latest version of the policy is now ready to formally vote on.

Details

Council members are required to vote on the below policy before 30 Sept, 2026 to officially approve or reject it. A full consensus is required, meaning a minimum of +3 votes, and no -1 votes after one week are required to approve this policy.

@jspaleta @shaunm @churchyard @bookwar @decathorpe @jonatoni @pbokoc @pboy @nimbinatus @t0xic0der

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.

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).
Research Space: Resources can be requested if a person or group has an idea that they would like to do some researching on. The idea should have the intention to benefit the Project, be self-contained (meaning it is small and has no major dependencies or impact on the wider project) and just needs a place to be experimented with first. This request must follow the exceptions request process outlined below. Please be advised that these resource allocations, if granted, will come with no guarantees, and infra maintainers reserve the right to delete repositories if there is no activity or resource needs become unmanageable, etc.

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, or Fedora Remixes, 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:

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.
Infrastructure Review: The Fedora Infrastructure team will conduct an initial review against the established criteria to assess technical feasibility and resource impact.
Consultation: If the request falls into a gray area, the Infrastructure team will escalate the ticket to the Fedora Engineering Steering Committee (FESCo) for technical review and decision, or Council for non-technical concerns.
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, Remixes 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.

Outcome/Impact

If the policy is approved, it will be merged to official Fedora documentation https://docs.fedoraproject.org/en-US/forge-documentation/

### Summary Council members are requested to vote on the proposed Fedora Forge Usage Policy by 30 September, 2026. ### Background The Fedora Forge Usage Policy proposal has been under community review for several weeks following the triggering of the Policy Change Policy. The Fedora Council agreed in the most recent meeting (23 Sept, 2026) that the latest version of the policy is now ready to formally vote on. ### Details Council members are required to vote on the below policy before 30 Sept, 2026 to officially approve or reject it. A full consensus is required, meaning a minimum of +3 votes, and no -1 votes after one week are required to approve this policy. @jspaleta @shaunm @churchyard @bookwar @decathorpe @jonatoni @pbokoc @pboy @nimbinatus @t0xic0der # **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](http://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). * **Research Space**: Resources can be requested if a person or group has an idea that they would like to do some researching on. The idea should have the intention to benefit the Project, be self-contained (meaning it is small and has no major dependencies or impact on the wider project) and just needs a place to be experimented with first. This request must follow the exceptions request process outlined below. Please be advised that these resource allocations, if granted, will come with no guarantees, and infra maintainers reserve the right to delete repositories if there is no activity or resource needs become unmanageable, etc. ### **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, or Fedora Remixes, 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. **Consultation:** If the request falls into a gray area, the Infrastructure team will escalate the ticket to the Fedora Engineering Steering Committee (FESCo) for technical review and decision, or Council for non-technical concerns. 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!](http://forge.fedoraproject.org/your-fas-username) ) 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](https://forge.fedoraproject.org/forge/forge/issues/new?template=.forgejo%2fissue_template%2fnew_organization.yml). 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**](https://docs.fedoraproject.org/en-US/project/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, Remixes 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**](https://forge.fedoraproject.org/forge/forge) 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](http://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](https://forge.fedoraproject.org/forge/forge/issues). 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**](https://forge.fedoraproject.org/forge/forge/issues) or ask in the[ **#fedora-admin**](https://matrix.to/#/%23admin:fedoraproject.org) Matrix channel. * **Reporting Code of Conduct Violations:** To report a CoC violation occurring on the Forge, please contact the[ Fedora Code of Conduct Committee](https://docs.fedoraproject.org/en-US/project/code-of-conduct/). * **Reporting Security/Legal Issues:** To report a security vulnerability on the platform, exposed secrets, or a [DMCA/copyright](https://docs.fedoraproject.org/en-US/legal/dmca/) violation, please immediately send an email to [Fedora Infrastructure team](https://docs.fedoraproject.org/en-US/infra/day_to_day_fedora/). ### Outcome/Impact If the policy is approved, it will be merged to official Fedora documentation https://docs.fedoraproject.org/en-US/forge-documentation/