design-proposals: Clean template and add feature lifecycle section

[lyarwood]

/cc @xpivarc
/cc @vladikr
/cc @EdDev

What this PR does / why we need it:

As discussed at the unconference for v1.5.0 [1] we should start documenting the expected lifecycle of a given feature within our design proposals before later moving this tracking to an issue.

This change cleans up the template, removing multiple top level headings, adding whitespace around headings and adds a final section defining the lifecycle of a feature.

[1] https://unconference.kubevirt.io/D62SngbSRXO1uhTAc8Ikqg#xpivarc-Feature-lifecycleFuture-of-proposals---1-1-1-1

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #286

Special notes for your reviewer:

Checklist

This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

• Design: A design document was considered and is present (link) or not required
• PR: The PR description is expressive enough and will help future contributors
• Code: Write code that humans can understand and Keep it simple
• Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
• Upgrade: Impact of this change on upgrade flows was considered and addressed if required
• Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
• Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
• Community: Announcement to kubevirt-dev was considered

Release note:

NONE

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign cwilkers for approval. For more information see the Kubernetes Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[iholder101]

Awesome to see this!

In order to provide some more guidance, I'd add sub-sections for alpha, beta and GA.

Suggested change

	## Feature lifecycle Phases
	(How and when will the feature progress through the Alpha, Beta and GA lifecycle phases)
	## Feature lifecycle Phases
	(How and when will the feature progress through the Alpha, Beta and GA lifecycle phases)
	### Alpha:
	### Beta:
	### GA:

The Kubernetes KEP template does so with a comment:

#### Alpha

- Feature implemented behind a feature flag
- Initial e2e tests completed and enabled

#### Beta

- Gather feedback from developers and surveys
- Complete features A, B, C
- Additional tests are in Testgrid and linked in KEP

#### GA

- N examples of real-world usage
- N installs
- More rigorous forms of testing—e.g., downgrade tests and scalability tests
- Allowing time for feedback

WDYT?

[EdDev]

And it should be clear that the phases are not mandatory, e.g. a feature can reach GA directly. Usually if it is trivial.

[lyarwood]

/close

@iholder101 thanks for the review but I think folks want to push ahead with the new enhancements approach in v1.5.0 instead now so I'm going to close this out.

[kubevirt-bot]

@lyarwood: Closed this PR.

In response to this:

/close

@iholder101 thanks for the review but I think folks want to push ahead with the new enhancements approach in v1.5.0 instead now so I'm going to close this out.

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-sigs/prow repository.

[lyarwood]

/reopen

[kubevirt-bot]

@lyarwood: Reopened this PR.

In response to this:

/reopen

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-sigs/prow repository.

[EdDev]

Thank you!

[EdDev]

And it should be clear that the phases are not mandatory, e.g. a feature can reach GA directly. Usually if it is trivial.

[kubevirt-bot]

Pull requests that are marked with lgtm should receive a review
from an approver within 1 week.

After that period the bot marks them with the label needs-approver-review.

/label needs-approver-review

[aburdenthehand]

@lyarwood Happy to merge this but it looks like it's still pending suggestions. Did you want to take a quick look?

[lyarwood]

@aburdenthehand thanks but #362 is really the future of this stuff, @vladikr would you still like me to land this PR ahead of the new repo and template being created?

/hold

[kubevirt-bot]

/remove-label needs-approver-review