nit: What information does this communicate that the previous paragraph doesn't communicate? Should it be skipped or combined with the previous paragraph?

Also, we aren't using GitHub Projects for this currently: https://github.com/cilium/design-cfps/projects?query=is%3Aopen .

Oh I see, I missed the PR description when I first read the PR 🤦

These statuses will be listed in the Cilium Feature Proposals (CFP) GitHub Project that will be added to this repository. Workflows are set to automatically set Provisional (when a new PR is opened), Implementable (when a PR is merged), and Withdrawn (when a PR is closed), but the other three statuses will have to be manually set. The SIGs will also have to be manually set.

How will we manage these? If this is automated somehow, great. If not, then I think this is creating more busywork that is likely to be neglected by the Cilium project unless you find someone specific who will volunteer to keep the CFP projects up to date. Almost every time we've tried to use projects or milestones etc. in the Cilium project, there's one person who pays attention to them for a few weeks, then they lose interest and the project gets stale and outdated. A big reason I see for this is that the benefits of managing this "virtual paperwork" are not high enough to make it part of our regular working process.

If this is something that SIG leads see value in and would be happy to help with, then I would encourage setting up something like that. On the other hand, if we don't have buy-in from anyone who would actively engage with this process, then I think it's the process that needs to change to fit the people, not the people changing to fit the process.

I'll CC in specifically @marseel , @hemanthmalla (on behalf of @cilium/sig-scalability) and @squeed (on behalf of @cilium/sig-policy) in case they have opinions about how to track CFPs within specific SIGs and whether sharing a project to track these things would be helpful for them.

The link here helps 👍

nit: To simplify the wording and make it accessible to readers from a variety of backgrounds, I would suggest to use more straightforward imperative wording, such as:

sidenote regarding the above feedback, while community members "are encouraged" and they may "want to bring further attention...", this wording is imprecise, and we've adopted a style guide for better communication since the previous version of this doc was written.

Is it experimental, or is it beta? These words have different connotations ranging from "Use at your own risk" to "Please run this in production and report your findings".

I recognize the need for a category like this between "Implementable" and "Stable", though I'm not familiar enough with process or how the process impacts human behaviour in order to have a strong opinion on how to portray a proposal in this status.

I can see benefits in leaning it towards wording like "experimental" as a way to incentivize contributors to work on moving the CFP towards "Stable" state, though I could equally see contributors simply ignoring the CFP process after it becomes "Implementable" and completely focusing on stabilizing the functionality to the point where it's production-ready.

I'll CC @youngnick in here in case he has some opinion about how a process like this should look, as I think he has more experience than me on this.

Related: For the Cilium project, this is likely to differ from other communities like Gateway API, because these designs in Cilium are targeted for typically one implementation in Cilium (one of the repos under this organization), and we have additional expectations about testing, docs, etc for that implementation as we accept changes. On the other hand when the entire project is a standard like Gateway API or Network Policy API in upstream k8s sig-network, then some of those requirements may end up in the design repo.

I guess related to the previous comment, we have the state of the CFP then the state of the feature. Each of these lines seems to describe the state of the CFP as tracking a specific state of the feature, though these terms like 'beta' or 'GA' are not currently defined anywhere, so it's a little hard to understand what those mean.

Is the rigorous testing intended for the design or the implementation?

How is this "Complete" state different from "Stable"?

To help inform the thought process, I have a PR (#36) that sort-of fits this category. I labelled it "Dormant" for now, because in this case the design review resulted in "Changes Requested", but I do not currently have the cycles to pursue the change further. The core idea is still worthwhile, but it hasn't proven critical enough to solve just yet. The idea isn't exactly "Withdrawn", but the specific design is practically speaking "Withdrawn". I'm not sure whether I would consider that one to be under "Provisional" or "Withdrawn" given that the primary blocker on moving it forward is just interest from a contributor to resolve the outstanding feedback and push it forward.