Hi @blc, the topic is worthy of discussion, but I think it might not be clear how the Fedora Council is supposed to action this ticket. If you want to have a general discussion, we should likely move this ticket to a Fedora Discussion topic instead.

However, if you are asking for formal input from the Fedora Council on this topic, we can offer recommendations as the Council. I suspect that many of us might like to see a Community Initiative proposed around Konflux, which would provide more levels of integration into Fedora governance conversations and provide Konflux leaders with an executive sponsor on the Fedora Council.

However, as this ticket is written now, I don't feel like it is very actionable without more guidance on your end, @blc.

In lieu of more input, I suggest closing this issue.

Sorry for the delay. I was on vacation, then at Flock. I will try to clarify the request by telling you about a prior time guidance from leadership was required. More than a decade ago the Fedora ARM team wanted to push armv7hl to primary architecture status. How to do this had never been documented, so it wasn't really clear what the minimum requirements were so the team didn't know if they were doing the right things to achieve the goal. After some back and forth, the topic was added to the FESCo agenda and we had a good discussion about what the parameters for inclusion should consider. This wasn't a "do these 10 things and you're in" type checklist, nobody expects that, but more of set of considerations that one needed to address sufficiently to make a change in Fedora that affected people beyond the ARM team, without putting undue burden on them. It took a few iterations, but we got there in the end. I regard it as a major success.

This past experience is the context in which this ticket was filed: I'm looking for guidance on how to proceed in a thoughtful manner, with a minimum of wrong-turns. In this case a piece of infrastructure is being built that, down the road, may affect many contributors. At first as something that is useful to some, and then over time, useful to many, and perhaps eventually used by all. It's not there now, this is early days, so the request is to share a few waypoints on that journey. Valuable feedback would be who to talk to, which standard Fedora processes to follow, any red-lines, timeframes, and anything else a person would want to know if they were making plans and wanted to do it as the benchmark for excellence in collaboration. I hope this makes sense. If not, please let me know.

Thanks for the clarification, @blc. I expect the answer you will receive is look into a Community Initiaitve because this is the primary vehicle for driving community-wide change over the span of 2-3 release cycles.

I triaged this ticket for the next Fedora Council meeting. We can commit to having a one-time discussion as the Council about this particular request, but there is not much to action the Council for here unless we have a draft proposal of a Community Initiative to review, together with the community.

Hi @blc, we had some discussion about this in the Fedora Council Matrix room this week and during todays council meeting. We understand that it is difficult to navigate a large, established community like Fedora, and it isn't always clear how to best introduce and build momentum for a new project. That being said, what was clear from Council members is that the Fedora Council does not wish to perscribe mandatory steps to the Konflux team on how to engage in the Fedora Community. Rather, we would like to encourage the Konflux folks to work towards engaging in the Fedora Community Initiative Framework.

We think this will be the most effective way to drive this kind of strategic, multi-release effort in Fedora. However, a successful initiative requires significant groundwork to build understanding, buy-in, and momentum within the community.

Therefore, we advise the Konflux team to focus on forming the following foundational steps, with the goal of being able to propose a Community Initiative to the Fedora Council:

• Practice Open Communication: Maintain a public space for communication like your public Matrix/Element channel, as the primary place for real-time discussion. This will help create a welcoming environment for community members. We also strongly suggest posting regular progress reports and updates to the Fedora Discussion forum. This creates a visible, asynchronous record of your work that the entire community can follow.
• Develop in the Open: Ensure all development happens in public repositories. Crucially, the most critical strategic and technical decisions should be made transparently in public forums, not in private JIRA tickets, internal documents, or closed meetings. This transparency is key to building trust.
• Create Opportunities for Contribution: Actively create and label well-scoped issues or tasks that are suitable for new community contributors. This is the most effective way to turn passive interest into active participation. Keep in mind that these new community contributors might need guidance to be successful.
• Use the Changes Process as part of the Community Initiative Framework: When you are ready to propose a significant change that will affect other contributors or the operating system as a whole, use the formal Fedora Changes process. This is the standard mechanism for getting broad technical feedback and buy-in for changes that impact a single Fedora release cycle. Change proposal(s) can form part of the Community Initiative plan for Konflux.

To be clear, the leadership and ownership for this work rests with the Konflux team. The Council's role is to provide guidance and support where possible, ie through a Community Initaitve, and not to lead the effort. With this guidance provided, we are now closing this ticket. If the team would like some additional guidance on how to navigate the Community Initiatives process, we would be happy to help and we look forward to reviewing a Community Initiative proposal in the very near future.