Last Thursday, 10 September, members of Fedora Council, Mindshare, FESCo and the wider community met to continue to workshop the Innovation Lifecycle proposal. This session focused on developing a process to mitigate against continuous feedback looping. This piece of documentation is intended to accompany the main Lifecycle process, and its use should be considered to be light in nature. The document is not 100% complete, but its nearly there 
The basic flow of the process was agreed to, and the remaining work is more or less polish, which can be done as part of writing the Innovation Lifecycle documentation when its ready to be proposed as an official process.
Below is the flow that the group aligned on, and also the agreements that were reached during the session.
SOP: When a Proposal is Returned for Refinement
Purpose:
For proposals that have completed initial approval from Council and requirements gathering for Sandbox entry, but have been returned by either Mindshare or FESCo for further refinement by the Fedora Council before re-submission to FESCo, Mindshare, or both for a decision. This process aims to ensure community feedback remains constructive, transparent, and time-bound to preventing endless revision cycles, while honoring everyone’s time and effort.
Scope & Applicability
This process applies when:
- A governing body (FESCo, Mindshare, or the Council) requests scope adjustments to a proposal, or has concerns on technical or community impact that need to be addressed.
In this case:
- The proposal returns to the Fedora Council for holistic guidance before re-entering formal review.
Operating Principles:
-
Constructive Direction: Feedback should focus on clear, actionable adjustments rather than open-ended brainstorming or flat-out ‘no’s’ without any reasons provided.
-
Bounded Revisions: To avoid circular discussions, each refinement phase operates under set criteria and time-frames.
-
Shared Stewardship: Re-review is a collaborative step to strengthen the proposal, not a restart of the entire proposal lifecycle.
Standard Operating Procedure:
1. Receiving the Decision & Guidance
When a proposal is referred back for refinement, the Proposal Owner will:
-
Consolidate Feedback: Gather the specific points of feedback or concern from FESCo or Mindshare into a single document or issue/ticket.
-
Set Expectations: The default intention for all proposals is to see them gain entry to the sandbox and be successful. However, the idea may fail to gain entry if some critical requirements cannot or will not be met. Proposal owners must be prepared to commit to doing the work required.
2. Council Refinement Sync (Time-Bounded)
The Fedora Council reviews the proposal alongside the proposer during a scheduled meeting or async review window (recommended: maximum of 2 weeks).
-
Scope the Refinement: Define specifically what changes are required for the proposal to be considered complete for resubmission based on the feedback received.
-
Set the Re-submission Criteria: Redraft the proposal (where necessary) that includes the adjustments and agree on a clear, explicit criteria that determine when the proposal is ready to move forward again.
3. Council Sign-Off & Resubmission
Once the exit criteria agreed upon in Step 2 are met:
-
The Fedora Council confirms the refinement phase is complete.
-
The Proposal Owner updates the official proposal repository or wiki page with a brief changelog detailing how the feedback was addressed.
-
The proposal is formally re-queued for decision by FESCo, Mindshare, or both.
4. Re-Review Window
To protect the proposal from infinite feedback loops:
-
Specific Review Cycle: Stakeholders (FESCo/Mindshare) are invited to provide feedback specifically addressing the newly refined sections, rather than reopening settled requirements.
-
Focus on Resolution: An alignment lead may be assigned from council to the proposal owner(s) in order to help reconcile conflicting viewpoints efficiently during the re-review phase(s).
-
Time-bound: A proposal may only return through the refinement process a maximum of two times. If a proposal exceeds this limit, this can be taken as signal that the idea is either not ready for sandboxing, or is not a good fit for the project in general.
Resolution & Escalation
If feedback during the refinement phase leads to conflicting recommendations that risk stalling progress:
-
The Proposal Owner and FESCo/Mindshare liaison present the specific point of divergence to the Fedora Council.
-
The Council provides a final consensus ruling or explicit recommendation to allow the proposal to proceed to voting.
Agreements, Proposals and TODO’s
AGREED: Mindshare and FESCo representative votes are mandatory for sandbox proposals.
AGREED: A proposal is permitted two refinement loops max. This is because the group felt that most of the requirements should be caught at the socialization/community feedback period, and at Council review as reps from FESCo and Mindshare vote here first. Some further requirements may be needed, but one to two refinement loops should be more than enough to cover things. If its not, the idea is likely to be either a wrong fit for the project, or not mature enough to be considered for the sandbox.
PROPOSED (and softly agreed): Mindshare and FESCo reserve the right to change their vote that was initially cast via their reps if a sandbox idea becomes out of bounds, or new information becomes available that may change either or both groups position on the proposal when it comes to their respective ticket queues.
TO-DO We need to have a policy that deals with a proposal being re-proposed over and over if its rejected. Open to suggestions. Maybe a cool-off period? I.e, repropose after 6 months with proof of change-log to initial proposal?
TO-DO: Investigate if the FPL Veto vote has ever been used in the past.
TO-DO: Define what a ‘strategic fit’ looks like/means for the sandbox and innovation lifecycle in general (rollover from last week, will be covered in an upcoming session).
Next Session Focus:
The next working session is scheduled for Thursday, 17 September 2026 1400 UTC. Details can be found in Fedocal, and the focus will be on what tooling the Innovation Lifecycle will use, eg git repo, wiki, etc.