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.