Fedora Strategy FAQ Part 1: What is Actually Changing?

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.

Categories: Council

4 Comments

  1. How would that work differently than pagure ?

    • Pagure is primarily a git forge, and all of its features are focused around that. Taiga is a project/workflow tool, and has features around that. There’s definitely some overlap in areas like tickets, and we’ll have to figure that out. I think some teams that have git-focused work will probably continue using Pagure tickets too.

  2. Hi Matt, this post clarifies comments from the previous post. Everything said here makes sense to me.

    Two considerations I had while reading:

    1. Project boards in Taiga are useful, but this change may be biased towards engineering teams. Many Mindshare member groups are not yet familiar with Taiga. Documentation and guidance is useful for teams manned mostly by volunteers. Before fully adopting Taiga as a standard, community-specific guidance to Fedora Teams should be available for those setting something like this up for the first time. I think this will help those teams be successful using Taiga in practice.
    2. I think unifying the Spins/Labs branding is helpful, from my period in Fedora Marketing vis-à-vis Fedora user communities. To make this change stick, some design work should go into spins.fp.o and labs.fp.o, since that is the most common engagement point for people using Spins/Labs. This could be a good conversation to start with the Design / Web Teams.

    Looking forward to what’s next. 👍

    • Thanks Justin! This is good feedback. Some stuff, as always, we’ll have to make up as we go along, and perhaps we can generate some documentation of best practices as we do that.

Comments are closed.

Copyright © 2019 Fedora Community Blog

Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.

Theme by Anders NorenUp ↑