Draft Council Proposal for the Fedora Innovation Lifecycle

Project Discussion
1

Hello everyone,

Thank you everyone for the feedback on my previous modest proposal. I’m coming back to you all with an updated draft of the Innovation Lifecycle Proposal. This isn’t the formal Policy Proposal announcement, but I’m hoping this draft is reasonably close to what the formal Policy Proposal will be.

I would appreciate any constructive feedback you have. There will be additional feedback opportunity during the formal policy process.

I have a wiki link of the draft here:

But I will also place it inline below so people can reply quote easily:

:link: Fedora Innovation Lifecycle

This proposal outlines an alternative structured process for introducing, developing, and potentially integrating experimental features, components, outputs, processes, or services within the Fedora Project that are too large or complicated to be realized as part of a single ChangeProposal process.

:link: Objectives

  • Foster Innovation: Encourage contributors to bring forward new ideas, technologies, and features that may be too immature for direct inclusion in a standard Fedora release.
  • Isolate Risk: Provide controlled environments and outputs where experimental changes can be tested, broken, and fixed without affecting the main distribution branches or the experience of general Fedora users and contributors.
  • Gather Early Feedback: Facilitate early community and stakeholder engagement to gather feedback, identify potential issues, and guide the development of the experimental concepts.
  • Establish a Path to Integration: Define clear criteria and a structured transition path for successful Sandbox projects to move toward becoming official Fedora features, services, or outputs.
  • Promote Transparency: Ensure all experimental work is visible and accessible to the broader Fedora community
  • Attract New Contributors: Make a place where innovation and experimentation are encouraged.

:link: Background/Why

Why not ChangeProposals? While the ChangeProposal process is suitable for a series of small changes, it can be difficult to use for large changes or a series of interlocking changes that need to be made together.

Why not rawhide? Rawhide is useful for coordinating updates to integrated components for Fedora Linux releases. It’s not well suited for experimentation concerning changes in how components interrelate or changes to the build infrastructure itself.

:link: Structure

The Innovation Lifecycle will consist of 3 primary stages:

  • Sandbox
  • Curation
  • Integration

Each stage will have explicit contracts agreed to as part of stage entry, which establish a timeframe with explicit review criteria to help ensure that sufficient progress is being made towards full integration. Projects that do not make agreed-upon sufficient progress will exit the Innovation Lifecycle pathway.

:link: Sandbox

:link: Entry

Sandbox entry requires project teams to open a Council ticket which will include a draft Sandbox entry proposal. This ticket will start a 2-week community feedback period where the Fedora community is able to review the proposal and provide constructive feedback. The project team can revise the Sandbox entry proposal as they see fit, incorporating the community feedback before Council takes up the proposal for a Sandbox admittance vote.

Sandbox proposal teams are encouraged to have informal community discussion prior to filing the ticket. The formal 2-week community discussion period after ticket filing starts with the opening of a Fedora project discussion topic. At the close of the 2 week period, Council will conduct a sandbox entry evaluation at the first available Council meeting, or via an asynchronous process.

It is expected that Sandbox entry proposals will have unique considerations, but all Sandbox entry proposals need to provide the following information for Council consideration:

  • What is the overall strategic vision for the full integration of this technology into Fedora?
  • What are the key benefits of using the Innovation Lifecycle process versus the normal ChangeProposal process?
  • Who are the primary users of the innovative technology: end-users, existing Fedora contributors, upstream ecosystem, downstream ecosystem, other?
  • Which existing Fedora Project SIGs or teams are identified stakeholders and will be participating?
  • What are the known policy deviations in the Sandbox stage that will need to be reconciled in the Curation stage?
  • Is there a viable fallback pathway for this technology if full integration into the Fedora project isn’t achieved? (Ex: Remix hosted by Fedora, downstream adoption)
  • What non-standard resources does this project need, and how are they being resourced during the Sandbox stage?
  • What is the expected contributor ladder during the Sandbox stage?
  • What are the metrics by which you will measure progress towards technical maturity, market fit, and community engagement?
  • What is the requested Sandbox review timeframe?
  • What are the sufficient progress conditions demonstrable via the agreed-on metrics?
  • Who are the Sandbox stage committed team members for the requested timeframe and what are their core competencies as it relates to the 3 primary review criteria pillars: technical maturity, market fit, and community engagement?

Council will make a Sandbox admittance decision based primarily on strategic fit for the Fedora Project, overall Fedora project capacity (so that there are not too many such projects in-flight), and an assessment of the ability of the Sandbox team to provide the agreed-on metrics in the review timeframe to make it possible to do a progress review required to successfully continue on in the lifecycle process.

Council is explicitly not evaluating the Sandbox entry proposal for technical viability. The intent is for the project team to use the Sandbox to potentially reach technical viability. Council needs to evaluate the progress criteria the team chooses for Sandbox exit are reasonable as a starting point for working with FESCO and other stakeholders in the Curation stage.

Inclusion into the Sandbox stage explicitly confers a time-limited use of the Fedora trademarks during participation in Sandbox and Curation stages. On exit from the lifecycle via an alternative pathway, it is expected that the technology team will need to transition to standard Fedora Remix branding guidance, unless Council grants continued trademark use under its authority via a separate trademark usage proposal request.

:link: Review

Sandbox Review will be initiated by the Sandbox project team via a Council ticket no later than 2 weeks after the agreed-on review target date. This ticket will start a 2-week community discussion period similar to the Sandbox entry ticket.

The Review ticket will include a progress review that addresses the agreed-on review criteria set forth in the Sandbox entry and will request one of the agreed-on progress actions set forth in the Sandbox entry proposal. The default set of progress actions will consist of:

  • Sandbox exit
  • Sandbox renewal
  • Curation stage entry

If Sandbox exit is requested, other community members will have a chance to stand up and make the case for transitioning this technology into a more traditional ChangeProposal process as part of the Sandbox exit, before any specialized integrations or Fedora infrastructure supporting the Sandbox project are spun down.

It is expected that any Fedora infrastructure specialized resources made available for the Sandbox stage will be spun down within the timeframe of a normal release cycle unless there is a transitional ChangeProposal under consideration. Once Fedora Council agrees to the Sandbox exit request, the technology team driving the Sandbox engagement should begin to transition to their fallback pathway (possibly outside of the Fedora Project infrastructure.)

If Sandbox renewal is requested, the ticket should also include an updated sandbox entry proposal with updated information, including target progress criteria and other changes.And the community feedback period will be treated similarly to Sandbox entry proposal, with the additional context of the previous sandbox cycle to aid in assessment. If curation stage entry is requested, the ticket needs to include a curation entry proposal and will outline deficiencies that need to be addressed during the curation stage.

:link: Curation

:link: Entry

Curation stage entry will require a proposal that details known deficiencies that must be addressed prior to full integration.

The Curation stage entry requires interaction with additional Fedora Project stakeholders to begin the work of fully integrating the technology according to the communicated strategic vision.

If Council approves the request for Curation entry, the first action is to create a Council initiative, identifying an initiative lead and a Council executive sponsor. These individuals will work to interact with other stakeholder groups which includes at a minimum: FESCO, Fedora infrastructure, and Fedora Mindshare to address deficiencies with regard to Fedora project policy reconciliation, infrastructure integration, and community governance.

:link: Review

The formal Curation stage review by Council will happen approximately on Fedora release cycle boundaries, to determine if progress is being made to addressing the deficiencies and is on track to being completed in the 18 month time frame expected from a Council initiative. If at the 12 month review point its clear that deficiency reconciliation isn’t possible, the project can begin its journey towards its alternative exit path and live on outside of the Fedora Project if one has been identified.

:link: Integration

:link: Entry

Entry into the Integration stage will be by a formal ChangeProposal that signifies that all deficiencies identified at the start of the curation stage have been mitigated to the satisfaction of the relevant Fedora Project stakeholders. Fedora Leadership stakeholders may choose to require that the Fedora Council engage in a sustainability review on a specified timeframe. Such a request would need to identify key sustainability metrics to incorporate in the review.

:link: Sustainability Review

The purpose of the sustainability review is to catch strategic projects that stumble with regard to longer term sustainability aspects and place them back into a curation stage as a way to potentially rehabilitate them by giving them some focused attention. Or if that’s not possible, provide a graceful adjournment so the project can refocus resources on other sustainable efforts.

:link: Standard Sandbox Infrastructure

There is no standard sandbox infrastructure as part of this initial policy proposal. I will be talking more with the CLE team concerning transitioning the communishift and forge infra as the basis of a standard sandbox offering that will help make this pathway more compelling to community project ideas.

Fedora Hummingbird: Taking the Hummingbird model to the full operating system
2

Thank you for the proposal. I am happy that we are exploring ways to improve the process for introducing larger changes into Fedora.

I appreciate that there are multiple review/revision stages to help the proposal owners to refine their proposal. In the current process, sometimes FESCo has to formally reject a Change or postpone discussion because a Change is underscoped or missing details about the Change’s technical implementation and benefits and impact on the rest of the distribution. I think this is discouraging for Change owners so hopefully having a more structured framework will help avoid this.

I think delaying the input from FESCo and other stakeholders to the next stage is potentially problematic. We don’t want there to be cases where people spend a lot of time incubating their change only for some major concern to come up later in the process when the other stakeholders get involved. This new process shouldn’t sideline FESCo or other decision-making bodies in Fedora besides Council, either, and I do think collecting high-level feedback from these bodies early in the process before deciding whether something is right for the Sandbox is useful.

For certain would-be Sandbox changes, they are mostly self-contained and just need time to incubate and get set up in Fedora (e.g., the Hummingbird project that plans to release container images as a new output). But there might be parts of more self-contained proposals are untenable or would require major FESCo or FPC policy changes (e.g., replacing Fedora packages with other components or including alternative kernels in outputs). Or other proposals could impact other distribution components or require a lot of infrastructure resources (Hummingbird is self-contained but would require some amount of builder resources). Or a proposal might fall under the scope of an existing WG or SIG. All of these cases would benefit from earlier feedback from the knowledgeable bodies .

1 Like
3

@jspaleta Thank you for drafting this. The structured pathway from Sandbox
through Curation to Integration is exactly the type of process that would
make it possible for larger, multi-component projects to responsibly
experiment within Fedora rather than having to build entirely outside.

The explicit metrics and progress review gates are particularly well-considered
— they address the “how do we know this is working” question before it becomes
a crisis of trust.

I’m watching this draft evolve and look forward to the formal Policy Proposal.

4

I try to account for the potential problems with delaying formal fesco involvement in a few ways:.

  1. The sandbox entry proposals requires the identification of known policy deviations that need to be reconciled. Nothing should show up at the curation stage and take anyone unawares. It needs to be in the sandbox entry proposal.

  2. If FESCO decides things need to be reworked… equivalent to rejecting a change proposal, that is a possible outcome of curation. We can put it back into the sandbox. We have that option. That would be a recommendation FESCO would make to council. But if FESCO doesn’t think this can be reworked.. then the technology take the alternative exit path.

  3. the alternative exit for the technology should be an acceptable outcome for everyone involved if reconcilation isn’t possible. Stating what that pathway is at the beginning makes that explicit for everyone, If by being involved in the Fedora Sandbox stage helped the technology mature, but ultimately goes on to live elsewhere like a downstream project, because we couldn’t reconcile that’ needs to be okay. It shouldn’t be thought of wasted time.

5

Well, I think there’s the potential for policy deviations or other issues to be missed this way, and also, when policy deviatations are identified, I don’t think simply listing them in the proposal text is sufficient. For example, the FPC’s Packaging Guidelines forbid packaging of alternative kernel packages and external kernel modules in Fedora. If an entire proposal is hinged on doing one of those things, I don’t think admitting it into the sandbox over the heads of the FPC and the kernel maintainers because the proposed technology isn’t fully matured is going to be productive in the end or a good use of Fedora’s resources.

6

There is a public discussion period for the Sandbox entry.

If there are hard no go policy deviations. We can have the public discussion prior to Council voting on entry.

Even in cases like this… an exit path of a Fedora Project hosted remix is within scope as a strategic decision.

For example like the Risc-V stuff right now exists as a Remix inside the project because that arch still has yet to be upstreamed kernel bits. There is a need for the output to live and breathe and get into the hands of people interested in working with Risc-V… and we do it as a remix…its a strategic remix.

I would actually say bring up a new arch would work in this framework… with the strategic goal being to make it primary arch.

7

Right, but as far as I understand it, the Riscv people are interested in getting things mainlined and eventually becoming an official Fedora architecture once the hardware is there.

Addressing problems like this should be planned as part of the initial submission. If there is not a semi-concrete plan to address the policy deviations and no discussion has been had with the relevant bodies about adapting polices or guidelines, I don’t think expending Fedora resources just for it to inevitably exit Fedora is necessarily a good use of said resources. Even in the FESCo Changes Process, things that impact Infra/Releng or the Packaging Guidelines (FPC) need to be discussed with those groups prior to FESCo approval.

8

Does the Sandbox Entry questions that need to be answered not address this?

There is a specific one asking which SIGs and Teams are participating.

Do you want to have an explicit one asking if FESCO has been consulted?

9

Yes, I think FESCo needs to be explicitly consulted for technical proposals, and Infra/Releng needs to be explicitly consulted if the change impacts their work, and the FPC needs to be explicitly consulted if the changes require Packaging Guidelines changes.

10

Following up on this…
The intent is the formal consultaton is the curation stage.

Because copr use is in scope in the sandbox… as people..experiment…

We should have process that ensures that the relevant groups are informed.. but that’s the public discussion.

FESCO has a liason on council. I would expect that person to be the consultation point for technical issues in the scope of Council’s role in approving entry into the sandbox.

11

I’m thinking about this more, and I’m wondering if some of the targets for the new framework can be handled in simpler ways.

  • People are already able to mostly “just do stuff” in Fedora as long as policies are followed. Anything that is legally permissible but against other packaging policies is allowed in Copr, as you pointed out.
  • Major distribution changes are already handled by the Changes Process. If something is larger or more complex, the proposal text would naturally be longer than less complex changes or split into multiple steps. There are shortcomings with the process, and FESCo has a ticket to work on improving the process, but I don’t think it’s inherently flawed.
  • We should have a lightweight request process for infrastructure that Fedora SIGs and WGs can use

The one thing that I don’t think we have a solution for is projects like Hummingbird that want to integrate into Fedora but need help moving through the steps, interfacing with the community and our policies/processes, planning work, etc. But I wonder if there’s a simpler way to do that that doesn’t involve two parallel change proposal processes.

12

I’m going to push back on the idea that change proposals can get longer and more complex and can be successful.

Once changes become large enough or radical enough they are a series of things..that have to be changed together.. or we get into the situatoin that modularity was..were a huge amount of work is frontloaded to make a detailed large plan..but it falls apart after there is commitment to integrate. I really don’t want to get into a situation ever again where we are asking the ChangeProposal process to do something as large.

Feel free to make whatever changes you want to the change proposal process to make individual changes easier to drive, because obviously that will help This process is meant to speak to larger or more radical ideas.

This process is an effort to solve the innovator’s dilemma that this project finds itself. I don’t think you can adapt change proposals enough to do what the introduction of a structured sandbox in this proposal does…which is ask people with the big ideas to actually prove to fedora leadership its worth looking it, committing to, to integrating fully. The sandbox structure is intended to show.. progress…towards a sustainable effort… its not just a good idea on technical grounds.

13

In particular… talking about policy that I expect the sandbox to be loose with generally.. is any policy associated with technical quality or user experience quality life expectations like upgrade/downgrade expectations.

Those are important aspects of full integration, when collectively the people who are working on the big idea in their head want to make the commitments to the users about their intent of having a working dependable output that will upgrade without a lot of manual user interaction to fix up.

But the sandbox is the place to step back from those sorts of policies.. with the intent to come into alignment with those policies in the curation phase once its clear the thing being built doesn’t need the freedom to make big changes to itself that requires fresh reinstall every week. But I also want the people bringing things into the sandbox to be explicit about that upfront. Hey everybody.. this thing in the sandbox is going to delibrately and knowingly break these specific policies.

-jef"The sandbox’s motto and creed to users coming along for the journey: ‘Good luck; Have fun; Don’t die’. Also surprising good movie.. watched it on the plane.. enjoyed. May watch again"spaleta

14

I can also imagine something like arch bring up.. like what riscv is going through right now fits into the sandbox. Arch bring up is rare, but never straight forward.

riscv bring up right now depends on some out of tree kernel modules that are making their way in… that’s a policy breach..but people are working on it. why does all of this riscV bring up work need to be outside the project boundary when the intent is to get this fully integrated?

Having a riscv remix available to touch and taste is beneficial for the eventually intetegration people are working towards.

Right now all of that work has to happen as a remix outside of the project..even though its intended to be fully integrated and its probably something that Council would identify as strategically important to get fully integrated if asked to do so.

Can it live as a remix sure. Would it benefit materially from being in the sandbox process? Maybe.

Right now all the interesting technical work towards eventual integration is happening outside of the project boundary..and that feels a little weird to me. Why do we make things start outside the project that are intended to be fully integrated once the technical work that brings it into policy alignment is completed? Why don’t we have a space for the big integration concepts to get attempted inside the project boundary? The sandbox is a space for the big things that has some structure so we don’t just let them linger forever in a sort of zombie state. Its not for every big thing, its for the big things leadership think are strategically important…but the implementation isn’t locked down yet.

-jef

15

I find the idea of a Fedora “project boundary” a little bit nebulous. What do you see as the project’s boundaries? It seems like, for the most part, Riscv is already being worked on by Fedora contributors and has a secondary Koji instance under the fedoraproject.org domain. AIUI, the main reason it’s secondary is for technical reasons (lack of suitable hardware to run as an architecture in the main Koji) and less so because of policy hurdles.

1 Like
16

Also there was discussion about this in FESCo open floor (meeting log) and the Council meeting today. Some questions/ideas/comments that came up that resonated with me (or that I brought up myself :wink: ):

  • In FESCo, there were mixed feelings and uncertainty from some members, but I don’t think anybody was outright against it.
  • It was recognized that teams working on larger projects within Fedora, whether within Red Hat or somewhere else, may want a more structured process around that work.
  • The process document is long and a little bit daunting. If it’s daunting to existing project contributors, would it be even more daunting to new people?
  • Will this bypass FESCo/other governing bodies? It sounds like the answer is ultimately no, after the initial Sandbox entrance phase is over.
  • Can it solve problems like Infra apps or other projects that have been worked on but eventually went out of maintenance a couple years later? There was some discussion about what can happen to Initiatives after they go through the final integration phase.
  • How does this interact with the existing Changes and Initiatives processes and the option to “just do it” when something is self-contained and does not impact the rest of the distribution? We don’t want to have four possible processes to pick from for the same thing.
  • What about a more lightweight process that wraps/links a collection/sequence of connected Change Proposals? (I believe this was brought up by @decathorpe and @bookwar. Please expand if you’d like or correct me if I paraphrased wrong.)
4 Likes
17

We had so many discussions about this topic, but when we put it finally in writing we lose quite a lot of context.

So rather than commenting on specific steps, I’d like to get into slightly meta conversation about what this proposal tries to achieve.

Framework vs process

We have many processes in the project: the “to become a packager do this”, “to do a system-wide change do that”, “how to request funding for an event” - these are all process examples. They are handled by the dedicated groups in the project and generally keep the project going.

The processes do not hang in the air, though. They need to exist within a certain framework. The framework essentially allows us to communicate.

So I see this proposal not as a replacement or change in the current processes which exist in the project. Rather I see it as introducing a new communication framework. It helps to shape how do we talk about things we are doing in and out of the project.

As an example: Fedora Editions (+Spins +Labs +etc) is also a framework. It is not a process, it is a way to structure the conversation about the large set of Fedora deliverables. And once we have the concepts and the language to talk about them, we then setup some processes for them (“how to become an edition”, “do we allow multiple editions..”).

Why do we need a yet another framework

Historically the default answer to “How to do X in Fedora” was “take X code from usptream, package into rpm and start maintaining it”. This is a good question and good answer. It is still valid for a wide variety of things.

But lately we have more and more people asking “how do I build something out of Fedora”, or “how do I build Fedora differently”.

Of course, it is not a totally new question for us, we dealt with Fedora Remixes before. But the way we dealt with them essentially was - “do whatever you like, wherever you like, and do not even talk to us”. (Unless you are RHEL, and then we have a completely different approach to you, starting from the existence of EPEL, and with a relatively recently addition of Fedora ELN)

Our view on Remixes was also relatively package oriented. We considered a Remix to be just a set of new rpm packages overriding the existing Fedora packages.

Nowadays remixing becomes more creative, there are different approaches to building artifacts, to installing apps, to processing updates and to fetching stuff from upstream.

We have more people seeing a classical Linux distribution not as the end result, but as a building block.

We see this happens in both the user-oriented space (see for ex. Flatpaks) and in the stable enterprise-oriented space (see for ex. Image Mode).

This increased downstream activity creates different styles of communication, different set of discussions and new set of problems.

We can no longer operate with clean downstream vs upstream language because our downstreams are no longer just passive consumers of all the things Fedora packaged.

What do we try to solve

“They” try to push something to Fedora without talking to “us”.

Side note:

Honestly speaking, I am rather disappointed in the communication culture we showed in a couple of recent discussions. And the way how it becomes normal to call every proposal a “push”.

Proposing something is talking. You can not say “talk to us before you start talking to us”. Proposal is one of the ways how you can talk.

It is not an offense to propose something while you have not figured all the details of what you are talking about. It is how you figure them out.

Likewise, it is not an offense to reject a proposal once new details are discovered.

And no, “don’t talk to us this way before you talk to us that way” is not better.

We have a communication problem. But attacking a person who dared to communicate to us in a not our preferred way, is not how you solve it.

Now, with that being said, what actually is happening with the proposals lately:

a person comes to the Fedora Council and says “In our project we started to do this cool thing, we want to make it part of Fedora. How do we do it?”.

The replies we give:

  1. Just package it.
  2. You should have talked to us before you started.
  3. What does “part of Fedora” even mean for this specific project?

The first one is obviously not an answer in increasing number of cases.
The second is not an answer at all.

The third one is the most honest reaction, but the catch is - neither the requester, nor the Council has an answer to it. And no, FESCo also doesn’t have an answer. The answer simply does not yet exist, and can not be easily derived by an argument out of thin air.

So what the Sandbox proposal does, is that it gives us a communication framework to handle such situations better.

The Sandbox stage of a proposal as I see it is essentially a public expression of the intent:

“I am remixing some Fedora content in some interesting way, I want to make it part of Fedora, help me”.

And then once we have the Sandbox and Curation concepts, we can discuss the process for them.

Concerns

I think the described sandbox approach is aimed at larger players (corporate or some organized community groups).

Of course anyone can use it. But for the work a single person can do in the project without becoming part of the group, the added bureaucracy is probably too much of an overhead.

And yes, corporations are better at marketing their initiatives than individual contributors, and if we talk about only those sandbox projects and nothing else we will miss a lot of the community work happening in the distribution.

I think the answer to this, is that we should be careful and not limit ourselves to the discussions of Sandbox projects and nothing else.

This is why I was thinking about keeping the refreshed and low-cost, and essentially self-managed Initiaves framework alive. It will not have as much structure, but it would help with communication.

3 Likes
18

What about a more lightweight process that wraps/links a collection/sequence of connected Change Proposals? (I believe this was brought up by @decathorpe and @bookwar. Please expand if you’d like or correct me if I paraphrased wrong.)

We wanted to postpone the initiatives topic for later, but we kind of have to discuss both to compare them here.

So let me first describe the rough vision of what a lightweight initiative could be.

A Lightweight Initiative alternative

The idea is rather simple: initiative is a self-managed container for Fedora Contibutors to store and show case the work they do in the distribution, which spans multiple changes in multiple releases.

How you would use it?

Submit a page to a doc repo with description or a ticket in Forge repo.

No approvals, no strict deadlines. Only the heartbeat check, that the owner is still active, can be reached, and considers the initiative valid.

Examples

Existing work which would have been called an initiave

  • Python2 to Python3 migration
  • SPDX support
  • Post Quantum crypto adoption

Isn’t it just a SIG?

SIGs usually describe areas of interest and ongoing work related to them. Initiatives describe projects which have an end goal. SIG can own an Initiative. Initiative can span multiple SIGs, or not have a SIG at all.

People can join a specific project initiative without “fully joining” a SIG.
Initiatives ideally should encourage drive-by contributors.

Why would you use it?

You are a Fedora contributor who want to work on something. You want to invite people to work with you, you want to make the work more visible.

So, imagine we agree on this one, which we didn’t yet. Does it make Sandbox redundant?

I don’t think so.

I think it really talks about different weight and different impacts on the project. The examples I listed above are truly important initiatives but they are essentially a business as usual thing. We know what needs to be done, we know why it needs to be done in Fedora, we have done similar things before.

Things like Fedora EPEL, Fedora ELN, Fedora Hummingbird or Fedora Flatpaks would not fit in this process. These are the things which might change the entire scope of the project. They might expand what Fedora trademark covers, they might change how outsider community perceives Fedora.

They need more investment in terms of leadership involvement, wider discussion, more hand-on experience. They have more to prove, and more to explore. These are the things which we are not sure what their long term impact is going to be but we don’t want to just disallow them because they are scary. We want to try them out and see where it leads us.

And that’s the purpose of Sandbox.

3 Likes
19

Well-said, @bookwar. Pulling out a couple of specific excerpts below:

You persuaded me that we need Initiatives after all. However, we need to re-imagine them. If we have the Sandbox, we could detach the things that work better in Sandbox from the Initiatives framework.

Assuming this is a starting proposal to workshop, it is practical to delegate authority. I could see Council investing up-front labor to design a process which collects structured input on the self-managed Initiatives. Someone also would need to be accountable for doing that heartbeat check at a regular interval too. (Part of the release schedule somewhere?)

I like the overall direction of the lightweight alternative. The question is, is this something Council would continue to own the data maintenance of the new Initiatives, or would it be handed off to a more appropriate Fedora team/SIG later?

20

Thank you for the consideration and the summary.

I’ve been on leave for a death in the family so I’ve been sort of in and out for the last month, but I’m catching up on things now and picking this back up.

1 Like