Feature Request Process

[ProdManagerSandra]

Feature Request Process

The following steps show the stages a Feature Request (FR) goes through.
Our goal is to make the journey of your FR transparent, easy to understand and to set the right expectations.

We believe the strength of our open development model lies in rapid feedback on OpenCloud - thats why feature requests are critical to building software that is loved by its users. The art lies in building software that fits everyone’s needs without turning it into a jack of all trades and master of none.

Step 1: Submission

Feature Request welcome
As an open source project, we welcome feature requests from anyone.

Meta

• Owner: Product Team
• Description: The feature request has been submitted and is awaiting (re)review by the product team within the next 30 days.
• Label: Status:Needs-Review

Step 2: Review

Product Team Review

The product team reviews the request with the goal to find an answer if the FR

Aspect	Key Question
User Value	Does this solve a critical problem?
High-frequency use case	How many users need this feature?
Strategic Fit	Is it aligned with our product goals and market differentiation?
Business Impact and ARR	Will this drive growth, revenue or retention?
Costs	What are our costs to build it and maintain it for many years?
Prioritization	How does it compare to other requests?

❌ Common Reasons to Say “No” (or “Not Now”)

• Lacks clear ROI relative to implementation cost
• Solves an edge case not aligned with the broader vision
• Introduces product bloat or complexity
• Not validated by user data or insights

Meta

• Owner: Product Team
• Description: The feature request has been submitted and is awaiting (re)review by the product team within the next 30 days.
• Label: Status:Needs-Review

or

Meta

• Owner: Submitter
• Description: Please provide the missing information so that we can re-review.
• Label: Status:Needs-Info

Step 3: Review Outcome

Based on the review, the request will be accepted or declined (close issue as won't fix). If it got accepted, planning and prioritization takes place as roadmap- or sprint item.

Meta

• Owner: -
• Description: The request doesn't align with product scope or long-term strategy. No further action will be taken.
• Close Issue as: Won't-Fix

or

Meta

• Owner: Product Team
• Description: FR got accepted and will be worked on via actionable stories. Planning and prioritization takes place as roadmap- or sprint item.
• Label: Status:Accepted

[dragotin]

Thank you, this is very cool as it makes our processes very transparent and inform our community on how decisions are made in the project. Maybe we can make it a bit more explicit how people should write FRs to make them more likely to be considered, ie. what information should be in etc.

A related topic to this is how we handle code contributions from community members that have not gone through this kind of review process before, but just land at some point. Would it be the same process to decide if we merge these, or do we need other criteria?

[ProdManagerSandra]

Hey @dragotin Yes, we have an internal Feature Request template that we can review together before I upload it here.

On the topic of code contributions from the community: thank you for bringing it up, let me have a think on how we could handle those and get back to you.