Adopt Fedora Innovation Lifecycle as Council Policy #564
Labels
No labels
category
budget
category
code-of-conduct
category
docs
category
elections
category
events
category
initiatives
category
mindshare
category
policies
category
spending-request
category
Strategy Summit
category
trademarks
Next Meeting
state
resolved
good first issue
help wanted
needs
changes
needs
reporter feedback
needs
triage
needs
vote
role
engineering
role
fca
role
foa
role
fpl
role
initiative lead
role
mindshare
scope
bug
scope
improvement
scope
new
state
approved
state
blocked
state
duplicate
state
invalid
state
wontfix
No milestone
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
council/tickets#564
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Council should adopt the proposed Fedora Innovation Lifecycle process as Council Policy
Background
The policy draft under consideration for adoption can be found in the Fedora wiki at:
https://fedoraproject.org/wiki/User:Jspaleta/Drafts/FedoraInnovationLifecycle
This is a final policy draft represents a lighter weight version of the initial straw proposal
This process being presented for adoption takes in feedback from the Fedora discussion thread and the FRCL meeting feedback.
Details
Steps to complete:
I request Council adopt this policy for a 1 year probationary period, during which time initial candidate Sandbox project proposals can be presented to enter the sandbox stage of the lifecycle process. It is expected that the first candidate projects will result in policy refinement proposals that council will need to consider as amendments to this policy.
Council will review the innovation lifecycle policy after 1 year, and may at that time make significant changes or shutter the process if its clear there has been no interest in using it during the probationary period.
During this first probationary year the FPL will work with the Red Hat CLE team, and the Fedora infrastructure team to refine the concept of a standard sandbox infrastructure offering in consultation with community interested in making use of this integration pathway.
The straw proposal was covered by LWN already:
https://lwn.net/Articles/1062579/
I've tried to address Brockmeier's constructive criticism in the the article he wrote by being more explicit in this final proposal by adding explicit community feedback periods as part of lifecycle stage entry/transitions.
Discussed in 2026-05-06 Fedora Council meeting.
The Council reviewed the drafted Fedora Innovation Lifecycle proposal. Feedback highlighted the need for clarity regarding gating, prerequisites, and infrastructure provisioning during the Review phase, as well as a request for concrete examples to accompany the policy. The immediate next step is to circulate a formal policy proposal draft privately among the Council for early feedback before advancing to the public Policy Change Policy process.
Follow-up Items
Next Steps: Review the upcoming formal policy proposal draft.
Owner: @jspaleta to share the draft with the Council via the private mailing list before Red Hat Summit.
As per the council meeting on Wednesday, June 3 2026, this proposal is still in progress. A draft is available for public review on discourse right now and a more focused conversation will happen after Flock. The council did agree that this needs to be surfaced to the community as much as possible to build maximum awareness. More information on the discussion can be found from the meeting logs https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-06-03/fedora-council-meeting.2026-06-03-14.07.log.html
This ticket status is In Progress and will be removed from the discussion column.
This was discussed in todays council meeting as a potential candidate to either replace or compliment a process to achieve the goals that the Community Initiatives framework was attempting to do.
Council will now be focusing more on this proposal while we have paused the Community initiatives process.
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-07-01/council.2026-07-01-14.01.log.html
This is currently on the Flock 2026 milestone, which has passed. Given the renewed attention this got at our July 1st Council meeting tied to pausing Community Initiatives, should this move to Fedora Linux 45 or Fedora Linux 46?
Assisted-by: Claude Sonnet 5 (1M context)
So I've given this a bit of a brief read though, and by no means a thorough one, and I think it misses a couple of key points. I am not necessarily going to highlight some of the points I think it's missed because I think the council should step back and better think this through.
It seems to want to compare the process to other Fedora processes and groups like the Change process or SIGs, I think it's actually completely orthogonal to any of that and as a result kind of misses the point.
Sanbox:
Overall I don't get the sandbox stage and I'm not sure what it's trying to achieve. For example either someone will have already engaged with the SIG(s) affected or actually wants to avoid them entirely to "innovate" and frankly at this stage who cares about polices and other such processes if you're just sandboxing something to see if it's going to hold water. All of those "processes" aren't innovative. Personally I've done this bit of the described process for dozens of things (eg various Raspberry Pi generations support) I've contributed to Fedora and why would I go and ask council for permission where I can just throw things at copr/containers/github pipelines or what ever ugly mess I hack together to see if the idea is going to hold water?
From a branding PoV I don't even think it makes sense to use proper branding at the sandbox stage, it's likely not expected to be widely used by the average user. From an infra PoV I think that's more interesting, but see above point about copr/containers etc.
Over all I think the whole sandbox thing is way too process heavy for something that maybe a scratch the itch kind of idea, and there's so many more straight forward ways of doing stuff like this. Frankly why would I ask for permission when I can beg for forgiveness later.
Curation:
This is what I think is likely useful, yet it has no where near the fleshed out details here that sandbox has, this is where all the stuff thrown at the wall to be made to work, whether those globs of binaries are at copr or containers or where ever need to be curated into something appropriate for Fedora, whether that needs to be polished packaging or assistance with licenses, or splitting the work into appropriate Changes. I say changes, as this could end up being a multi release cycle process to go from crawl to walk to run. I also this looks purely inwards when it says "work with" what about outwards to work with upstream projects and other such pieces?
Integration:
Entry: Again some of these need to be reordered, and frankly if all that comes out of all of this is a single change proposal it's a hell of a lot of work for very little "innovation" :)
Sustainability: This should actually be step one, and I think it's an oversight it's last and not the very first step. Any proposal should be reviewed to see if it's sustainable before all the rest of the work is done. A proposal to "Make all android phones be able to run Fedora" would IMO never be sustainable and that should be identified in the first step not the last, we fail the community and the contributor of the proposal if we don't identify something that is going to say burn out the contributor and disappoint the community from the outset to set proper expectations.
Overall I like the idea of an innovation lifecycle but it doesn't feel very innovative and I'm not sure what I would get out of it for things like adding "RPi5 support" or "Out of the box open source AI on the Edge", which are some of the many recent things I've been using Fedora to "innovate" with and it actually feels like more work where in most cases I can just land it in Fedora without most people knowing ;-) and not even bother with Changes.
I think what the council needs to do is coming up with what they would like to achieve around innovation before putting proposals in place that I feel miss the mark, happy to discuss further :)
The TL;DR is why would anyone want to do this over just doing what ever they please in a container/copr?
Current draft is here:
https://fedoraproject.org/wiki/User:Jspaleta/Drafts/FedoraInnovationLifecycle
Discussion of current draft:
https://discussion.fedoraproject.org/t/draft-council-proposal-for-the-fedora-innovation-lifecycle/190996