Add maturity criteria

[joestringer]

One of the things that is missing from the current CFP template and process is the notion of maturity criteria. Put simply, when should a feature be considered good enough for alpha, beta, stable status. This issue is intended to gather feedback on this aspect and how we can facilitate thought and discussion around feature maturity as part of the CFP process.

The CFP process doesn't necessarily need to encompass this - we could just publish guidelines on individual repositories and deal with feature maturity as part of the code review process. However if there is a CFP for a particular change, it would be useful to encourage designers and reviewers to consider maturity targets during the design process.

[joestringer]

We had a little bit of discussion about this during today's @cilium/sig-scalability discussion (notes here). One of the driving ideas is "what are 2-3 things you would want the feature to have in order to support it in a production environment?". A few brief considerations for maturity are listed below before reaching "stable":

• Observability to make sure things work
• Fail-safes so when things don't work, they fail gracefully
• Demonstrated real-world usage in production

[marseel]

The CFP process doesn't necessarily need to encompass this - we could just publish guidelines on individual repositories and deal with feature maturity as part of the code review process. However if there is a CFP for a particular change, it would be useful to encourage designers and reviewers to consider maturity targets during the design process.

I think it's alright to not know all criteria during initial CFP development for beta or stable status.
But having this even as a placeholder in the template would encourage authors / reviewers to come back to CFP later on and fill in gaps that were discovered during the development process. This would allow us to review again at a later stage once we know more about a particular feature.

It's also a good idea to decouple it from regular code PR that marks the feature as stable, to fully reconsider what are limitations / gaps that need to be resolved.
Example from K8s
A similar example for CiliumEndpointSlices from Cilium: cilium/cilium#31904 where we created "graduation" criteria later on.

[joestringer]

CFP-39757 includes some initial wording, but I consider that to be mainly informative for how we aim to structure docs and not a definitive solution to this issue. That said it may be helpful to inform the solution to this issue. Link: #72 (comment)