This post is part of an FAQ series about the updated strategic direction published by the Fedora Council.

What is actually changing?

This strategy is an ideal we’d like the project to work towards, but it’s also a path that we’re already on. Some parts of this aren’t a change at all, but a clarification of the general consensus over the last few years.

Project Terminology and Teams

We want “Fedora” to be the Project. For things Fedora makes, we’ll describe them as “Fedora Thingname”, like “Fedora IoT” or “the Fedora RPM Package Collection”. I’ve been saying this for a while, but I want to make it official. (Just as “Red Hat” isn’t RHEL.)

We’re going to set up a hosted Taiga instance (more on this soon). Anyone in Fedora will be able to create a project there, and every team in Fedora should. This will create a directory listing which will supplant The Subprojects wiki page and have three significant advantages:

1. Available all in one place
2. Searchable in a reasonable, non-wiki way
3. Not a wiki: inherently self-updating and sortable by activity

This is the minimum required to be a Fedora Team. Teams may have more formalized membership, a charter with rules for voting, regular meetings, regular reports to FESCo or Mindshare, etc. We decided against formalizing rules for words like “Working Group” or “Subproject” and instead agreed that any Team can use those labels if they like.

Teams providing services should formalize a menu of offerings. They should describe the criteria by which those offerings are provided. I think the Council should provide some standard ideas for reasonable criteria. These could include team structure and activity level, user base, a link to current Fedora Objective, etc.

More Autonomy

We need a way for Teams to release artifacts in a self-service way. The Astronomy spin (to pick a random example) should not need to wait for release engineering to make a release. In fact, they might choose to make new releases around the cadence of their most important included software. At the same time, since the Team can do it themselves, Release Engineering might also not be on the hook for building artifacts for spins with a niche audience or that don’t meet some other criteria.

We need to allow for non-RPM building blocks somehow. I mean, not in a technical way but in a rules way. We need to allow for RPMs built in non-traditional ways (the source git idea). No solution is forced to consume these, but we shouldn’t block someone from providing them, either. For example, Silverblue may want to provide some Flatpaks that are built (in an open and transparent from-source way) straight to Flatpak rather than going through RPM. Or AI/ML may want to generate and ship container images with python wheels built specially.

 

We need to relax policies on what Solutions are allowed to do. We also want to drop the Spins/Labs naming thing — it’s confusing to people even within the project. Solution-makers should know their audiences best and should be able to make more technical choices — the things currently known as Spins should be able to offer different defaults and presets, even including enabling different module streams by default. Solutions should not require Spin SIG (or FESCo) approval on technical merit or perceived feasibility.

Overall

We need to be able to adapt to the changing world without taking 18 months to do so each time.