Fedora Council 2026 Strategy Summit daily briefings & summaries (@ Tirana, Albania)

Hi Fedora community! :waving_hand: The Fedora Council has gathered in Tirana, Albania, for the 2026 Strategy Summit. Over the next three days, we are meeting to align on the strategic direction and priorities for the Fedora Project in the coming year.

We are trying something new this year! To ensure transparency and keep y’all involved in real-time, I am posting daily summaries of our sessions as replies to this thread.

What to expect

  • :eyes: Daily Insights: A brief overview of the topics discussed and key decisions made each day.
  • :speaking_head: Live Feedback: We encourage you to share your thoughts and questions in this thread. This allows the Council to review community feedback while we are still gathered in person.
  • :memo: Final Report: A comprehensive, long-form write-up detailed the full outcomes will be published on either the Community Blog and Fedora Magazine after the Summit concludes.

Please watch this thread for the Day 1 summary coming shortly! :rocket:

11 Likes

I am excited to see the outcomes and direction for 2026 and beyond! :raising_hands: Thank you for doing a daily summary so we can all follow along in the discussion!

And enjoy Tirana - make sure @jonatoni takes all of the council members there to the ā€œmust haveā€ dish in Albania! :slight_smile:

4 Likes

Day 1 Summary: Strategy & Governance

Yesterday (Tuesday) kicked off the 2026 Strategy Summit in Tirana. :albania: Our primary focus was refining the long-term governance structure of the project and exploring new ways to empower community-driven innovation.

1. The ā€œFedora Project as a Weird Universityā€ Model for Governance

@jspaleta presented the ā€œState of the Strategy,ā€ introducing a new metaphor for how we view Fedora Project’s governance: The (Weird Fedora) University Model.

In @jspaleta’s view, the Fedora Council acts less like a corporate board and more like University Regents. Our goal is to charter and support various ā€œDepartmentsā€ (SIGs, Editions, Working Groups) that have the ā€œacademic freedomā€ to innovate, while the Regents and Administration ensure the lights stay on, the campus is safe, and resources are distributed fairly.

Red Hat looks at Fedora as a primary ā€œInnovation Engineā€ funding the research, while Fedora provides the ā€œCampusā€ where that innovation is distributed and graded.

Discussion then happened about if and how we can change or adjust Red Hat’s view on the project. No specific action items were created.

2. Exploring Open Collective

We discussed the need for a more flexible financial structure to handle community engineering grants and sponsorships. The Council is officially investigating Open Collective as a potential technical platform to manage these funds. We discussed the topic of Fiscal Hosts and some alternatives

At this time, we want to try the Open Collective platform on a small-scale project, like funding a specific event. But then we want to come up with a framework to include ā€œengineering grantsā€ to the picture, possibly modelled similarly to Outreachy.

We are not yet announcing a specific Fiscal Host entity at this stage, as legal and finance reviews are still ongoing.

Action: @jspaleta is going to get the initial approval from Red Hat. More details are going to be presented at Flock to Fedora 2026.

3. Defining ā€œFedora Membershipā€

The major topic of debate on Tuesday was defining what a contributor and a contribution are in Fedora. After nearly three hours of intense debate, we ultimately decided that we did NOT want to create any definition, broad or narrow, for what makes someone a Fedora contributor or what is actually a valid contribution to Fedora. This probably sounds strange!

However, the reason we ultimately decided not to define a contributor or contribution is because we do not want to limit the possible contribution paths in Fedora. But as we need a more formal structure for the governance of the project, we decided to architect something brand new: a Membership status and a ā€œmembership teamā€ (name TBD) which would approve and evaluate member applications. Specifically, this would be a system that relies on rules, like membership in specific groups or existing members ā€œvouchingā€ for others in order to be sponsored as a Fedora ā€œmember.ā€

  • Broadening the Base: This body would review membership applications from contributors whose work (design, marketing, advocacy) doesn’t fit the existing automated checks (e.g. membership in the packager group).
  • Active Lifecycle: We are also discussing a policy for the expiration of inactive memberships. To ensure our voting body accurately reflects the current active community, membership should be a status you maintain through activity, not a lifetime appointment.

Action items: @jflory7 to start working on the proposal to bring to the Fedora Council and the Fedora community. We hope to use this status for the F45 election cycle (Dec 2026)

4. The Road to Flock

Everything discussed today are concepts, not a decree or even a defined proposal. Our goal is to refine these concepts into concrete drafts that we will present at Flock to Fedora 2026. We want to use the conference as the primary venue to workshop these ideas with the community face-to-face and gather community consensus.

Specific milestones will come as we get to the end of the Strategy Summit, but we are working with the Fedora release cycles (i.e. F44 and F45) and Flock as major checkpoints.

9 Likes

Day 2 Summary: Initiatives & Engagement Metrics

Hello Fedora community! We are back in Tirana for our final day of the Fedora Council Strategy Summit. This reply is the summary of our Day 2 discussion on Wednesday. The main focus of our Day 2 discussion was hearing updates from all of the ongoing Community Initiatives, and spending time discussing how we measure engagement via an exercise planned by myself and @alking.

As a reminder, what we are sharing here are mostly updates or conceptual ideas that will need more discussion and community input over the next year.

Git Forge 2025 – @ryanlerch

Fedora Forge is already available and we are in the migration phase. We need Council, Mindshare and Docs teams to lead by example and migrate from Pagure & GitLab to Fedora Forge by F44 Release Party.

For private tickets the groups will use e-mail based workflows as a backup. This work will be presented at the F44 Release party.

We had a larger discussion about private tickets. FESCo and the Fedora Council will temporarily use the e-mail based workflow for the Fedora 44 release cycle, or once Fedora Infra upstreams the private issues feature.

All projects must finish their migration from Pagure.io (not dist-git) by the end of May 2026. Projects like Code of Conduct and GDPR trackers have requirements which we cannot cover with e-mail workflow, thus these are only two projects to have an exception.

Dist-git migration will be scheduled for later.

Aleksandra will open a Council ticket for the git forge policy topic, with the plan of proposing a first-draft of the Fedora Forge usage policy by mid to late March.

Mindshare Committee – @t0xic0der

@t0xic0der presented a summary of the work done since the F42 Mindshare Committee election, particularly the renewed charter with three pillars: Regional Event Support, Contributor Recognition, and Digital Ambassadorship. Progress was shared on documentation revisions for Regional Event Support, Fedora Badges Revamp Project and Fedora Contributor Health Metrics for Contributor Recognition and procedure enhancements for Digital Ambassadorship.

The Fedora Mindshare Committee will lead by example in migrating the GitLab issue tracker to Forgejo by F44 release.

The follow-up discussion mostly covered topics of swag design (e.g. leaflets, stickers, etc.) and distribution. Mindshare Committee will work with relevant teams to create an inventory of available designs that can be produced by F44 release. The Mindshare Committee also needs to maintain an inventory of the contents for the existing Event Boxes in Raleigh, North Carolina, USA and Brno, CZ.

By Flock, the Mindshare Committee should also provide an update to the Fedora Council about updated process documentation for producing new swag, whether part of the event box or to be produced locally. Additionally, the Council asked to deliver a minimum of 200 stickers each for the ā€œFedora Loves Python/Rust/Forgejo/etc.ā€ stickers as a test. This will go into the NA and EU event boxes to start with Flock to Fedora 2026 as the first deadline. The Council expects to have additional conversation internal to the Mindshare Committee regarding the process.

Fedora Docs 2025 Initiative - @pboy & @pbokoc

The initiative is ongoing, has regular meetings and is working on migration to Fedora Forge. There is also community buy-in and a couple of people have provided analyses of existing content (the old Sysadmin Guide and Quick Docs).

Peter and Petr talked about involving the rest of the project more, especially maintainers and QA, specifically through Changes and Release Notes. Need guidance and motivation/reminders for Change owners to actually supply release notes for their Changes; further need SIGs, package owners, etc. to start considering docs in their workflows, develop usage docs and at least report changes, if not submit docs PRs by themselves.

We discussed that there is no process to ensure that release notes are filled for already approved changes. We’d like to see if we can use Fedora Forge issues better for tracking the Release Notes completion for Fedora Changes. @humaton will provide some demo to FESCo by the end of March.

In the future we’d also like to have a ā€œdocs matrixā€ for each release - a list of docs that must be updated for each release - and monitoring for non-release-specific docs (Quick Docs etc.) to check for age and flag for review based on date of last revision.

ā€œThe Contribution Funnelā€

The interactive session is mostly around the contributors funnel. What brings people further from the lurker to first-time contributor and all the way down to leadership positions. It was a very active discussion, but without explicit action items. Fedora Council will have a follow-up video call on this topic later.

Fedora Atomic Initiative – @nimbinatus

The renewed initiative has regular meetings on Matrix and an active discussion channel via Matrix and occasional Discussion posts (like the renaming survey and related thread). More Discussion posts will be incoming, and everyone in the community is welcome to join in via Matrix and Discussion posts. New contributors are exploring Konflux as a possible pipeline system with help from the upstream Konflux community.

The initiative currently focuses on dev infrastructure which enables experimentation. There was a follow-up discussion regarding future plans regarding governance, integration with the rest of the Fedora project, and quality criteria. However, we discovered that there were larger questions raised as a result of the initiative beyond the scope of this discussion. No explicit follow-up items were created. More discussion is needed, as noted.

There will be an Atomic presentation at Flock. Another action item is created for an Atomic SIG. We would like to set it up by the Fedora 45 Release party.

6 Likes

Day 3 Summary: Engineering

Hey Fedora folks! This is the third and final summary post of the face-to-face meeting of the Fedora Council as part of the 2026 Strategy Summit. This summary is coming now, at the end of Day 3, because we just concluded the third and final day, and we do not have the morning tomorrow to sleep on a summary. :smile:

So, the main focus for Day 3 was all about engineering in Fedora. Specifically, we covered three topics: the official relationship between Fedora & Flathub and the overall strategy of Fedora Flatpaks, Konflux, and a general retrospective about how the 2026 Strategy Summit went.

Flatpak & Flathub

@jspaleta proposed five problem statements about the current situation and challenges he hopes for the Fedora Council to collaboratively address:

  1. Problem 1: Enable Flathub by default OR prefer Fedora Flatpaks
  2. Problem 2: One person is creating all Fedora Flatpaks
  3. Problem 3: Mission statement for Fedora Flatpak SIG
  4. Problem 4: Relationship with upstream
  5. Problem 5: Underlying federated technology issues in Free Desktop spec

To address these five problems, we mapped out a few next steps and action items:

Problem 1: Enable Flathub by default OR prefer Fedora Flatpaks.

  • @jspaleta: Council would like weekly updates and participate in the conversation, if needed, on the Flathub Change proposal.

  • @jspaleta: Figure out the process of how to get Council more informed about the Fedora tech discussions and Change proposals, so that Council can provide strategic guidance when needed.

Problem 2: One person is creating all Fedora Flatpaks.

There is a ā€œlottery factorā€ situation in Fedora Flatpaks. Council is aware of the problem and looking for solutions. We are expecting a proposal from the EPEL lead which could address this issue.

Problem 3: Mission statement for Fedora Flatpak SIG

Currently, the Flatpak SIG does not have a clear mission. The Council thinks that there is a lot of potential. We need to hold a separate working session on this topic.

The Council discussed ideas around Flatpak runtime development and maintenance, security verification, and quality assessment. There needs to be verification that whatever Flatpak app features work in our use case also work for our users. There also needs to be ownership of the Flatpak-related release criteria. Maybe we need a ā€œFedora Readyā€ label for Flatpaks apps?

Problem 4: Relationship with upstream

We discussed the concern of whether being a complete distro is still a mission of the Fedora Project. There are acknowledged fears in the community about this.

  • AGREED: We need to make a statement that we are friends with Flathub! (Fedora Loves Flathub stickers?) Flathub complements what Fedora is doing. Technical details not included.

  • @bookwar to own the post-Summit follow-up.

Problem 5: Underlying federated technology issues in freedesktop spec

We discussed the existing cross-project interest to form a working group around Flatpak standards and freedesktop specifications. We agreed that it is important for the Fedora Project to participate.

The possible next step would be for some Fedora representatives to join the Linux App Summit (April 2026, Brno).

We would like to encourage Fedora community members willing to improve federation features of the Flatpak technology to apply for travel funding.

Konflux

Council discussed the Konflux project and possible requirements the Fedora community might have for the infrastructure services and the build system.

We agreed that use of Konflux as an experimental pipeline implementation for the Fedora Atomic Phase 2 Initiative should continue. This allows the project to explore the space without forcing the technology on contributors/packagers and allowing the project to identify issues before they could affect the distribution.

Follow-up discussions will happen asynchronously. We plan to provide some updates by the Fedora 44 Release Party.

Strategy Summit retrospective

This discussion focused on two branches: the immediate, short-term actions for the next two weeks and a general retrospective on how this year’s Strategy Summit went.

We spent a lot of time mapping our action items to milestones like F44, Flock, and F45. But it was also evident that we needed to look at the immediate next steps for the next few weeks, to ensure that the momentum we built here is carried through to the rest of the year.

Here is a quick overview of what the community can expect next as we wrap up the Council Strategy Summit:

Week 7 (9-13 February 2026)

  • @jflory7: Convert the 25 February 2026 Council meeting to a video meeting about the Council Strategy Summit, to be opened with a presentation by @jspaleta and plenty of time for community Q&A.

  • @humaton: Advocate for the outcomes of the Council Strategy Summit to Fedora Infrastructure Team, and involve other Council members, if needed.

  • @jflory7: Set up the ā€œticketsā€ repo for the Council on Forgejo, with the intent that we migrate our current issues on Pagure, including private issues, at a later date into an ā€œarchiveā€ Forgejo repo.

  • @jflory7: Notify FRCL about the 25 February Fedora Council video meeting

Week 8 (16-20 February 2026)

  • @jspaleta: Prepare the presentation for the Fedora Council video meeting on 25 February, request feedback from other Council members as needed.

  • @bookwar: Open a new Council ticket for creating a Fedora Forge usage policy ticket (should be on Forgejo)

  • @jspaleta: Explore options for where GDPR compliance processes can be hosted in the interim, while Forgejo implements private issues (e.g. GitLab?)

Week 9 (23-27 February 2026)

  • Fedora Council video meeting on 25 February 2026 at 10:00 AM US ET

  • @jflory7: Prepare a public Fedora Magazine report (with Council support) about the 2026 Strategy Summit, key outcomes, and next steps following the Fedora Council video meeting

Open for feedback!

We agreed that this Fedora Discussion topic is the best place for the community to discuss with the Council about the outcomes of our Strategy Summit. Additionally, this is a great place to surface questions in advance of the 25 February 2026 video-based meeting. We will have time for live Q&A there, but we will also open up questions to be asked in advance from what comes up in this Fedora Discussion topic from now until then.

I hope this is useful for the community to summarize what happened and where the Fedora Council is hoping to guide the Fedora community in 2026!

3 Likes

Could you elaborate on what a ā€˜complete distro’ is, and what being one or not entails?

1 Like

There is no strict definition of the concept, it is not a specification. But there are some implicit expectations on what functionality a ā€œgeneric operating systemā€ provides to its user. You can connect to Internet, you can play music, you have a weather app..

You don’t want to buy a car from a vendor and than learn that the seats for the car need to be bought from another vendor. If you were in such a situation you would be rather disappointed.

Mainstream users don’t, but I build my own bicycles with components from many stores, and I build my own Fedora Linux from many sources, so I’m not so sure.

I certainly like that Firefox is included in Fedora repo. Where do we draw the line at ā€˜complete’? Debian has more packages than Fedora - but I use Fedora - why?

But let’s short-circuit an abstract discussion - what does ā€˜complete distro’ mean in the context of the council discussion at this time? It is something about ā€˜upsteam’ and ā€˜Flatpak’ - is someone claiming that Fedora without Flatpak is ā€˜incomplete’?

2 Likes

If we want this to be useful this must be widely communicated to the rest of the community ASAP. In addition, a channel for ad-hoc questions could be useful. That way people could record their questions and later watch the recording.

Are we limiting who is voting now [1]? Why? I joined Fedora as a contributor because I wanted to vote for someone I knew (I was an user of course). So I guess, that won’t be possible in the future (?)

This IMHO just amplifies the disparity in votes for ā€œpopularā€ candidates. It also forbids users [1] from participating. Notice that a membership that can expire and must be awarded by proving some contributions would impact all elections but the impact will be greater at Council and Mindshare as they only require FPCA.

Scenario: I contribute to Fedora as a packager but after a period I need to stop doing the technical work. After a year I still use Fedora and I spot a candidate at the Council election that I would like to vote for. I cannot do it anymore because my membership expired.

Scenario 2: I am a Fedora user that likes X, I spot a Council candidate that wants to promote that in the Fedora strategy. I cannot vote for them because I am not a ā€œcontributorā€.

I am also aware of the Elections Guide [2].

[1] I understand we are limiting by FPCA currently and by fedora user I mean someone that has a FAS account and has signed the FPCA.

[2] Making sure you're not a bot!

I deleted my previous comment because this is summarize my concerns in essence.

1 Like

I believe the essence of a functioning democracy is in the inclusion of a broad a base as possible.
One of the biggest barriers to entry to Fedora right now is feeling valuable and gate-kept.
There has been a perception on some peoples part that Fedora elections could be hijacked - but is this reasonable? Fedora functions well as it is. Keeping people out may well contribute to the decline of the next-generation of users and maintainers.

1 Like

Folks, keep in mind that Council folks are traveling home today after 3 days of 8-hour meetings, so replies will be delayed :slight_smile:

But do keep the questions coming. We will try to address as many as possible here, at the video call on Feb 25, and at Fedora events.

I will post more about the membership idea later today or tomorrow, but as a spoiler, the goal was not to shrink the voting rights in comparison to what we have now. I think the idea we want to propose will make it even more open in some ways.

5 Likes

Sounds awesome!
Enjoy your travels home and we can’t wait to hear more!

Disclaimer: Below is Aleksandra’s interpretation of the membership discussion. Other Council members may chime in. As the Fedora Council in the next couple of months we will be working on a shared draft, which will then become a proposal which we will present to the community.


The discussion tried to address a couple of issues:

  1. The non_cla group policy is easy to game as we don’t have a strict policy for when the FAS group can be created. FAS groups is a tool which may be used for a myriad of different purposes across Fedora Infrastructure. Some of those groups are useful for contribution estimation, but some are just a utility. And while Fedora doesn’t have the issue with the elections being gamed yet, the more ā€œmainstreamā€ we become, the more risky it gets.

  2. There are types of contribution which do not really lead to a person being added to any FAS group. We currently essentially force those contributors to ā€œsneakā€ into some groups, which maybe not relevant to them, not because of an evil intent, but because there is no other option to give them the voice.

We started the conversation with an attempt to list all possible contributions to the Fedora Project, so that we can find a way to successfully track each of them. That exercise proved to be futile. There are many different ways people contribute to the project. Even if we list the current known ways, we don’t want to restrict people’s creativity. We actually want to encourage people to come up with other ways and show us what can be done.

(At certain point in the discussion I even came up with the definition that a Fedora Contributor is a person who wants to be a contributor and is able to tell us how they think they contribute )

This is not a very practical approach though. And we do need some formal process for the elections mechanics to work.

So we want to have a process for contributors to ā€œregister to voteā€. We called it Membership, but it may not be a good name for it. (Suggestions are welcome)

The idea is basically that:

  1. any contributor using one of the standard contribution paths (packager, doc writer, event organizer..) which already have the way to track the contribution, get their ā€œright to voteā€= membership automatically based on the specific well-defined FAS groups they are already members of.

  2. there is additional process to apply for or to propose a person for the membership status, even when they work outside of the existing defined roles. For example, a person spends a lot of time helping folks with support questions. You, as a current voting member of Fedora, can nominate them, and they get their voting rights directly.

So far it sounds as rather open process, not very different from the current status quo. There is one important detail though:

We want membership to have an expiration date. This is already de-facto the standard for the packagers group right now. Afaik, if you stop being active, you will lose your packager status and packager rights. We’d like to make it mandatory that those known contribution paths mentioned in 1), which auto-grant you voter rights, define their expiration process in a way that makes sense to them.

Basically, if you contributed to Fedora Core 4 and then has not logged in FAS since then, you are a Fedora Contributor, and we are forever grateful. But you are not eligible to vote in Fedora 44 release cycle.


Now there is one thing in the previous comment I want to address specifically.

The question is: Would not it be better to just give voting rights to as many people as possible without any restrictions?

And my answer to it is - No.

Fedora is a volunteer-driven project. And as such it is critical for us to understand the difference between users and contributors. Users have demands and expectations. Contributors have intent to help the project to work on these demands.

We do care about our users, but we must be considerate towards our contributors.

I believe that it is important to set the expectation that Fedora elections is not a popularity vote for Fedora users to tell Red Hat which features they like to see done. It is a way for Fedora contributors to agree on which features we, as contributors, are going to work together, in whatever way and capacity available to each of us.

And I’d like to underscore, the ā€œworkā€ here should be taken as broad as possible. Every bit counts. But i believe it still has to be a requirement.

2 Likes

To note: No one ever said that everyone and anyone unrestricted should be able to vote in Fedora elections.

Your understanding of this council discussion is excellent, if not exceptional, and I whole-heartedly agree with it.

1 Like

Doesn’t this mean that such a possible decision would be individual and subjective? Given this specific example, shouldn’t there be some criteria and shouldn’t it at least be discussed with other members of the community?

1 Like

For what it’s worth, this is not a hypothetical. When Fedora used to have release names, we would put them up for a vote, and in one early election, we saw people making large numbers of accounts just to support a name. This lead to the ā€œCLA+1ā€ bar for voting, not intended to gatekeep, but just to restrict voting to Fedora contributors.

I think the risk here is low, but it’s not zero. Imagine if a YouTuber decided they wanted to troll Fedora and have all of their loyal fans brigade vote them into a committee, where they promptly cause trouble until we’re forced to ban them.

I don’t know what the perfect balance is here, but I also don’t think we want to just open voting to every ā€œperson|bot|AIā€ on the Internet.

3 Likes

There will definitely be criteria, in fact, basically the entire session was all of us coming up with criteria and then counteracting them with edge cases, because there’s always an exception to any rule. We’re trying to find a way to make sure that everyone in the Fedora community has a vote, no matter how exactly they’re involved, while keeping out bad-faith actors.

There will definitely be further discussions involving the whole community - this isn’t some kind of an edict made by a group of people in robes holding torches, it was just brainstorming. (I’m still disappointed about the lack of robes and torches, though. :smiley:)

3 Likes