📖CAEP proposal v2: expectations and timelines

[vincepri]

Signed-off-by: Vince Prignano vincepri@vmware.com

What this PR does / why we need it:
This PR iterates on the CAEP template making it more aligned with the expectations we (as a community) would like to have a fully fleshed out proposal before it becomes a PR to this repository.

In more details, this PR:

• Cleans the template to be more direct and explicit.
• Removes duplicated sections.
• Adds Glossary section with a link to the Cluster API book glossary.
• Rewrites the non-goals section as Non-Goals/Future Work, to be clear none of the points are blocking other folks' work.
• Makes it more clear of expectations for the Proposal section, such as details about the design, implementation, and having diagrams to refer to.
• Makes the Implementation Details section required.
• Makes most parts of Additional Details section optional. This section was called "Design Details" in the KEP template, although doesn't really align with how Cluster API has operated so far and being in alpha.
• Promotes the Upgrade Strategy section to be required and top level.
• Provides a clear timeline in Implementation History.

[vincepri]

/assign @timothysc @ncdc @detiber

[vincepri]

/assign @justinsb @justaugustus

as well, for more feedback

[ncdc]

Seems reasonable, thanks!

[vincepri]

Once we reach consensus if this gets merged, I'll make sure to reach out to folks writing proposals and CC them here

[detiber]

I don't necessarily like the idea of removing the Merge early concept, otherwise we are likely to get hung up on bikeshedding before getting proposals in.

[vincepri]

In the timeline below, I expressed that proposals ideas should be communicated in an issue or community meeting for initial feedback. Originally, the merge early was to get just motivation and goals in place, which so far hasn't been enough to get consensus.

[detiber]

Shouldn't data model changes be listed under implementation details?

[vincepri]

I looked at the bootstrap proposal, and those are part of the Proposal

[detiber]

This seems more in line with implementation details than the high level proposal description.

[vincepri]

Same as above

[detiber]

We should likely keep this as required going forward.

[vincepri]

Let's do this in another PR? I would like to think together through the items listed under there and make it more explicit what we'd expect users to write up here

[timothysc]

Perhaps just add upgrade strategy. Downgrade is fraught with peril.

[vincepri]

sgtm, anything else we should add to the notes?

[timothysc]

/lgtm
/approve

PSA @fabriziopandini - FYI on slight format update.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: timothysc, vincepri

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [timothysc,vincepri]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[vincepri]

/cc @detiber @chuckha @amy @noamran @michaelgugino @juan-lee @CecileRobertMichon @justaugustus @randomvariable @rudoi @dennisme @liztio @frapposelli

for updating the in-flight proposals with the new format and expectations

[k8s-ci-robot]

@vincepri: GitHub didn't allow me to request PR reviews from the following users: dennisme, noamran.

Note that only kubernetes-sigs members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

/cc @detiber @chuckha @amy @noamran @michaelgugino @juan-lee @CecileRobertMichon @justaugustus @randomvariable @rudoi @dennisme @liztio @frapposelli

for updating the in-flight proposals with the new format and expectations

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[frapposelli]

/lgtm