New process for handling virtualization proposals #362

vladikr · 2024-12-02T15:38:51Z

What this PR does / why we need it:

This PR is based on #288 and similarly suggests creating a new kubevirt/enhancements repository to manage KubeVirt Enhancement Proposals (VEPs).
However, this proposal suggests a structured process for prioritizing enhancements, focusing review and development efforts, and improving collaboration across Special Interest Groups (SIGs).
Each VEP will serve as the single source of truth for its feature, tracking its design, progress, and associated bugs, ensuring transparency and focus during development cycles.

Release note:

None

dankenigsberg · 2024-12-03T11:42:27Z

design-proposals/new-proposals-framework.md

+# Design
+
+The process includes the following key components:
+1. **VEP Creation**: VEP authors will initiate proposals via PRs to the `kubevirt/enhancements` repository.


Can we add here a link to a VEP template, or a reference to KEP's?

dankenigsberg · 2024-12-03T11:43:29Z

design-proposals/new-proposals-framework.md

+1. **VEP Creation**: VEP authors will initiate proposals via PRs to the `kubevirt/enhancements` repository.
+2. **SIG Review and Collaboration**: Each VEP will have a target SIG, and the SIG will assign a dedicated reviewer to oversee the proposal, collaborate with other SIGs as needed, and provide feedback or veto when necessary.
+3. **Centralized Prioritization**: At the start of each release cycle, a centralized mechanism will prioritize accepted VEPs, focusing community efforts on these.
+4. **Visibility and Tracking**: The Author of an accepted VEPs will open an issue to track their progress, maturity stages (alpha, beta, GA), and list the associated bugs. And user feedback


Can we add a template for such issue?

Eventually, we will. I don't think we should overload this PR with this.
I think eventually it should look similar to the k8s tracker: kubernetes/enhancements#3521

@lyarwood has already created a proposal for a template: kubevirt/kubevirt#13167
I think, we need to move it to the new project, once it's created.

dankenigsberg · 2024-12-03T11:44:26Z

design-proposals/new-proposals-framework.md

+1. **VEP Creation**: VEP authors will initiate proposals via PRs to the `kubevirt/enhancements` repository.
+2. **SIG Review and Collaboration**: Each VEP will have a target SIG, and the SIG will assign a dedicated reviewer to oversee the proposal, collaborate with other SIGs as needed, and provide feedback or veto when necessary.
+3. **Centralized Prioritization**: At the start of each release cycle, a centralized mechanism will prioritize accepted VEPs, focusing community efforts on these.
+4. **Visibility and Tracking**: The Author of an accepted VEPs will open an issue to track their progress, maturity stages (alpha, beta, GA), and list the associated bugs. And user feedback


Suggested change

4. **Visibility and Tracking**: The Author of an accepted VEPs will open an issue to track their progress, maturity stages (alpha, beta, GA), and list the associated bugs. And user feedback

4. **Visibility and Tracking**: The Author of an accepted VEPs will open an issue to track their progress, maturity stages (alpha, beta, GA), list the associated bugs and user feedback

design-proposals/new-proposals-framework.md

dankenigsberg · 2024-12-03T11:47:47Z

design-proposals/new-proposals-framework.md

+Luboslav Pivarc
+Vladik Romanovsky


Suggested change

Luboslav Pivarc

Vladik Romanovsky

- Luboslav Pivarc @xpivarc

- Vladik Romanovsky @vladikr

fabiand

Great to see this topic being pushed forward again.

fabiand · 2024-12-03T13:15:30Z

design-proposals/new-proposals-framework.md

+The process includes the following key components:
+1. **VEP Creation**: VEP authors will initiate proposals via PRs to the `kubevirt/enhancements` repository.
+2. **SIG Review and Collaboration**: Each VEP will have a target SIG, and the SIG will assign a dedicated reviewer to oversee the proposal, collaborate with other SIGs as needed, and provide feedback or veto when necessary.
+3. **Centralized Prioritization**: At the start of each release cycle, a centralized mechanism will prioritize accepted VEPs, focusing community efforts on these.


Who and how will this priorization be taking place?

Effectively, all the approved proposals before the dev cycle will become the projects' priority for that cycle. PRs belonging to the approved proposals will be prioritized (dev and reviews bandwidth)
If there are too many, we will prioritize them during the unconference. sigs will set the priority.

+1 for SIGs being in charge of the prioritization.

A small note: when I say prioritization I think mostly on reviews, and not on dev work. The dev work should be done by whoever is interested in implementing the proposal, but the review must be done by sig/root approvers. In other words, as Kubevirt maintainers, we owe VEP reviews, but we are not obligated to implement them.

Effectively, all the approved proposals before the dev cycle will become the projects' priority for that cycle. PRs belonging to the approved proposals will be prioritized (dev and reviews bandwidth) If there are too many, we will prioritize them during the unconference. sigs will set the priority.

The dev cycle opens once we hit feature freeze and branch main for the previous release. As such we need to be careful suggesting that only approved proposals will be prioritised by the unconference as that might not be enough time for folks to pivot from the previous release.

IMHO the unconference is just an opportunity to discuss and refine the list of possible proposals for the release. I think I've suggested previously that proposals being fully approved should instead be a goal by a later milestone such as alpha. Using v1.5.0 as an example that could look something like this:

2024-10-22 v1.4.0 FF (VEPs for v1.5.0 can be drafted before or after this when folks have bandwidth)

2024-10-29 v1.5.0 Unconference (VEP discussions, refinement and initial prioritisation)

2024-12-18 v1.5.0 Alpha (VEP approval deadline)

2025-01-15 v1.5.0 Beta0

2025-02-12 v1.5.0 FF

There's definitely an argument to have the unconference a few weeks later so folks have more time to prepare VEPs but we would still want time after the unconference to let any unresolved issues be worked out before the alpha deadline.

Thank you @lyarwood !
I fully agree with this. We need to start and adjust as we go.

+1 on elaboration of the term "mechanism". I'd say that the VEP proposers and approvers would publicly discuss the relative priority of the VEPs and decide which of them are scheduled to the upcoming release.

I merely wanted to say that all accepted VEPs will become the projects' priority.

The acceptance will be done via a central function.
If there is support for the VEP in the community and someone who is committed to implementing it, it should be accepted.
PRs belonging to these accepted VEPs will be prioritized. Meaning that there shouldn't be a relative priority between the accepted VEPs.

Let me try to rework this bullet point.

I noticed that in k8s there are two types of documents:

Enhancement tracking and backlog

How to target a contribution (EP, bugfix, etc.) into a release milestone.

IIUC this design proposal is similar to 1 while the centralized prioritization is also related to our release process.
Maybe we should create a separate doc that describes our release procedure and how VEP should interact with it.

@dankenigsberg I reworded this.

@enp0s3 we will definitely need to update an existing doc or write a new one. I'm not sure yet. Maybe @aburdenthehand will advice once this PR is merged.

fabiand · 2024-12-03T13:16:25Z

design-proposals/new-proposals-framework.md

+- Uniform process 
+
+# Approvers
+The following individuals are proposed as the initial approvers for the kubevirt/enhancements repository. These approvers will be responsible for ensuring VEPs meet the required standards, align with the project’s goals and best practices.


How did we end up with this list?
What is the reasoning and the tradeoffs?

This is only a suggested list.

As I mentioned in the document, the goal is to gradually transfer responsibility to the sigs as they mature and show commitment to the project as a whole, not only to the specific group.

To kickstart this process, we need a small group of people who will be committed to this process and who are not acting as SIG chairs.
I don't see a benefit in having a large list of approvers who are effectively inactive.

If anyone else would like to commit to this work, they are more than welcome to step up and add a name here.

I'm also conflicted to whether we need a small list of approvers for this work instead of simply all of the sig approvers. Anyhow each VEP will be owned by a target SIG, as mentioned above.

I'd at least add here that we aim that in the future this work would be done by SIGs, which I see as part of their core responsibility.

The goal is to eventually shift responsibilities toward the SIGs. However, this PR not only proposes changing the mechanics of how we manage proposals in KubeVirt but also asks the SIGs to adopt a different mindset.

As SIGs take on more control over VEPs, it is essential for the approvers to prioritize the benefit of the entire project over their downstream priorities or the interests of individual SIGs.
Unfortunately, there are many examples where this was not the case.

This is why I think we need a transition period that would allow SIGs to mature and adjust while keeping the centralized oversight.

FWIW, we could add here the current list of the community repo approvers, excluding those who are conflicted.

iholder101

Looks great.

Thanks you @vladikr for pushing this very important topic forward!

iholder101 · 2024-12-03T15:45:37Z

design-proposals/new-proposals-framework.md

+1. **VEP Creation**: VEP authors will initiate proposals via PRs to the `kubevirt/enhancements` repository.
+2. **SIG Review and Collaboration**: Each VEP will have a target SIG, and the SIG will assign a dedicated reviewer to oversee the proposal, collaborate with other SIGs as needed, and provide feedback or veto when necessary.
+3. **Centralized Prioritization**: At the start of each release cycle, a centralized mechanism will prioritize accepted VEPs, focusing community efforts on these.
+4. **Visibility and Tracking**: The Author of an accepted VEPs will open an issue to track their progress, maturity stages (alpha, beta, GA), and list the associated bugs. And user feedback


+1

In Kubernetes the issue number also serves as a proposal's unique ID. I think we can borrow this idea.

iholder101 · 2024-12-03T15:46:33Z

design-proposals/new-proposals-framework.md

+5. *Single source of truth**: Each VEP will be the authoritative reference for the associated feature. This aligns with the Kubernetes KEP process. It will ensure that each enhancement
+Includes all the relevant information, including the design and the state.


Maybe we can emphasize here that whenever the design / api / limitations etc change the VEP should be updated as well with a PR

Who is responsible to keep the VEP in sync with the current state of the code?

Who is responsible to keep the VEP in sync with the current state of the code?

As I see it, and this is how it works in Kubernetes as well, the workflow should look something like this:

The developer / assignee proposes a VEP, which contains requirements for graduating from alpha to beta.

The VEP is approved and merged.

The assignee is responsible for implementation.

Once the feature is ready to graduate to Beta from the assignee's perspective, a PR will be introduced to update the VEP. The PR will set a target release for Beta graduation and will explain how the requirements for Beta are fulfilled and whether they have slightly changed. The assignee will possibly have to prove it by providing a list of major implementation PRs.

Approvers would need to review the VEP, become convinced that the requirements are both good enough for graduation and are truly fulfilled.

The VEP will be updated, the feature would graduate.

TLDR: There are two parties here. One is the assignee who's the one having the biggest interest / motivation to get the feature towards graduation. The other is the SIG/project maintainers who focus on graduating only mature enough features.

Therefore, It's the assignee's responsibility to make the updates, and maintainer's responsibility to review and ensure it is properly done.

FWIW, it could be possible that assignees change during the lifecycle of the feature (even k8s suffers from this issue). In which case the burden will fall on to SIGs (esp members with admin rights to the repository) to update the issue and keep it in sync.

@alaypatel07 I agree.
It's important to emphasize that if the assignee at some point is not willing to promote the VEP anymore, it's the SIG's responsibility to reflect that and keep the VEP in sync, but it's not its responsibility to continue the implementation. If there is enough interest and another assignee is willing to step in, that's great, but if not, the SIG can eventually decide to revert and drop the VEP.

iholder101 · 2024-12-03T15:49:48Z

design-proposals/new-proposals-framework.md

+- Uniform process 
+
+# Approvers
+The following individuals are proposed as the initial approvers for the kubevirt/enhancements repository. These approvers will be responsible for ensuring VEPs meet the required standards, align with the project’s goals and best practices.


I'm also conflicted to whether we need a small list of approvers for this work instead of simply all of the sig approvers. Anyhow each VEP will be owned by a target SIG, as mentioned above.

I'd at least add here that we aim that in the future this work would be done by SIGs, which I see as part of their core responsibility.

alicefr · 2024-12-04T08:09:08Z

design-proposals/new-proposals-framework.md

+1. **VEP Creation**: VEP authors will initiate proposals via PRs to the `kubevirt/enhancements` repository. [Design proposal template](https://github.com/kubevirt/community/blob/main/design-proposals/proposal-template.md)
+2. **SIG Review and Collaboration**: Each VEP will have a target SIG, and the SIG will assign a dedicated reviewer to oversee the proposal, collaborate with other SIGs as needed, and provide feedback or veto when necessary.
+3. **Centralized Prioritization**: At the start of each release cycle, a centralized mechanism will prioritize accepted VEPs, focusing community efforts on these.
+4. **Visibility and Tracking**: The Author of an accepted VEPs will open an issue to track their progress, maturity stages (alpha, beta, GA), list the associated bugs, and user feedback


Do we have a definition of alpha, beta and GA somewhere? Or is it the meaning that kubernetes is using?

We do have this: https://github.com/kubevirt/community/blob/main/design-proposals/feature-lifecycle.md#releases.

Some of the k8s characteristics I remember from the top of my head:

Beta features are (usually) on by default.

Alpha can be dropped without a warning and has no backward compatibility considerations whatsoever.

When there's a good reason for it, there could be sub-stages like Beta1, Beta2, etc.

The changes from BetaN (N being the latest beta) to GA need to be minimal, especially API changes.

jean-edouard · 2024-12-04T15:07:35Z

/cc

lyarwood · 2024-12-09T11:34:35Z

design-proposals/new-proposals-framework.md

+The process includes the following key components:
+1. **VEP Creation**: VEP authors will initiate proposals via PRs to the `kubevirt/enhancements` repository.
+2. **SIG Review and Collaboration**: Each VEP will have a target SIG, and the SIG will assign a dedicated reviewer to oversee the proposal, collaborate with other SIGs as needed, and provide feedback or veto when necessary.
+3. **Centralized Prioritization**: At the start of each release cycle, a centralized mechanism will prioritize accepted VEPs, focusing community efforts on these.


Effectively, all the approved proposals before the dev cycle will become the projects' priority for that cycle. PRs belonging to the approved proposals will be prioritized (dev and reviews bandwidth) If there are too many, we will prioritize them during the unconference. sigs will set the priority.

The dev cycle opens once we hit feature freeze and branch main for the previous release. As such we need to be careful suggesting that only approved proposals will be prioritised by the unconference as that might not be enough time for folks to pivot from the previous release.

IMHO the unconference is just an opportunity to discuss and refine the list of possible proposals for the release. I think I've suggested previously that proposals being fully approved should instead be a goal by a later milestone such as alpha. Using v1.5.0 as an example that could look something like this:

2024-10-22 v1.4.0 FF (VEPs for v1.5.0 can be drafted before or after this when folks have bandwidth)

2024-10-29 v1.5.0 Unconference (VEP discussions, refinement and initial prioritisation)

2024-12-18 v1.5.0 Alpha (VEP approval deadline)

2025-01-15 v1.5.0 Beta0

2025-02-12 v1.5.0 FF

There's definitely an argument to have the unconference a few weeks later so folks have more time to prepare VEPs but we would still want time after the unconference to let any unresolved issues be worked out before the alpha deadline.

lyarwood · 2024-12-09T11:37:00Z

design-proposals/new-proposals-framework.md

+
+# Implementation Phases
+
+1. **Preparation (Pre-v1.5)**:


The dev cycle for v1.5.0 is already underway so just merge this with the second bullet?

lyarwood · 2024-12-11T16:07:31Z

/lgtm

enp0s3

@vladikr Thank you! going over the process and the comments, it makes sense to me.

dankenigsberg · 2024-12-11T16:35:51Z

design-proposals/new-proposals-framework.md

+
+## Repos
+
+- **Impacted Repository**: `kubevirt/enhancements` and kubevirt/community


Suggested change

- **Impacted Repository**: `kubevirt/enhancements` and kubevirt/community

- **Impacted Repository**: `kubevirt/enhancements` and `kubevirt/community`

for consistency

dankenigsberg · 2024-12-11T17:58:07Z

design-proposals/new-proposals-framework.md

+The process includes the following key components:
+1. **VEP Creation**: VEP authors will initiate proposals via PRs to the `kubevirt/enhancements` repository.
+2. **SIG Review and Collaboration**: Each VEP will have a target SIG, and the SIG will assign a dedicated reviewer to oversee the proposal, collaborate with other SIGs as needed, and provide feedback or veto when necessary.
+3. **Centralized Prioritization**: At the start of each release cycle, a centralized mechanism will prioritize accepted VEPs, focusing community efforts on these.


+1 on elaboration of the term "mechanism". I'd say that the VEP proposers and approvers would publicly discuss the relative priority of the VEPs and decide which of them are scheduled to the upcoming release.

Barakmor1 · 2024-12-15T14:33:39Z

design-proposals/new-proposals-framework.md

+
+## Motivation
+
+KubeVirt’s current approach to proposals is unstructured and has outgrown the community repo, making it difficult to adequately manage both the repo and the design proposals. The current process does not provide a way to prioritize development and review efforts during the development cycle, nor is there a way to derive a roadmap for a specific release. The process also lacks any formal SIG involvement. Being in the community repo also makes it difficult to grow the reviewer and approver list as there are conflicting purposes.


vladikr · 2024-12-15T19:06:35Z

I believe I addressed all existing comments.
I'd prefer not to approve my own PR (perhaps I had to let someone else post this).
If we all agree to start with his process let's approve this before the v1.5 alpha deadline.

Barakmor1

In general, I believe we need to update the current process, and this seems like a step in the right direction. Thank you!

Barakmor1 · 2024-12-15T20:30:06Z

/lgtm

fossedihelm

Looks great overall! I agree with the proposed process. Few comments below about details, otherwise LGTM

fossedihelm · 2024-12-16T07:31:30Z

design-proposals/new-proposals-framework.md

+1. **VEP Creation**: VEP authors will initiate proposals via PRs to the `kubevirt/enhancements` repository. [Design proposal template](https://github.com/kubevirt/community/blob/main/design-proposals/proposal-template.md)
+2. **SIG Review and Collaboration**: Each VEP will have a target SIG, and the SIG will assign a dedicated reviewer to oversee the proposal, collaborate with other SIGs as needed, and provide feedback or veto when necessary.
+3. **Centralized Prioritization**: At the start of each release cycle, all accepted VEPs will be designated as the project’s priority, focusing community efforts on the associated pull requests. Acceptance will be based on community support and a commitment to implementation.
+4. **Visibility and Tracking**: The Author of an accepted VEPs will open an issue to track their progress, maturity stages (alpha, beta, GA), list the associated bugs, and user feedback


Which repo will these issues be filled? kubevirt/enhancements?

Yeah, exactly!
I commented about this in the thread. Lee has already a PR ready with the new template that we will just move to the new repo.

fossedihelm · 2024-12-16T07:40:58Z

design-proposals/new-proposals-framework.md

+5. *Single source of truth**: Each VEP will be the authoritative reference for the associated feature. This aligns with the Kubernetes KEP process. It will ensure that each enhancement
+Includes all the relevant information, including the design and the state.


Suggested change

5. *Single source of truth**: Each VEP will be the authoritative reference for the associated feature. This aligns with the Kubernetes KEP process. It will ensure that each enhancement

Includes all the relevant information, including the design and the state.

5. **Single source of truth**: Each VEP will be the authoritative reference for the associated feature. This aligns with the Kubernetes KEP process. It will ensure that each enhancement includes all the relevant information, including the design and the state.

fossedihelm · 2024-12-16T07:42:48Z

design-proposals/new-proposals-framework.md

+4. **Visibility and Tracking**: The Author of an accepted VEPs will open an issue to track their progress, maturity stages (alpha, beta, GA), list the associated bugs, and user feedback
+5. *Single source of truth**: Each VEP will be the authoritative reference for the associated feature. This aligns with the Kubernetes KEP process. It will ensure that each enhancement
+Includes all the relevant information, including the design and the state.
+The VEP owner is responsible to update it as its development progresses, until it is fully mature (or deprecated).


As mentioned above by others, I think we need to emphasize that, in case of the author's unresponsiveness, the fallback will be the sig itself.

Indeed, however, I think that the commitment from the author to be responsive and to be able to implement this feature in a timely manner should be part of the review process.
I don't see how sigs will be able to take responsibility for a VEP and implement it themselves.
I think we need to start the process and improve this document as we go.

Agree! Thank you!

iholder101 · 2024-12-16T11:46:42Z

Thanks a lot @vladikr. This is a very important step in the right direction.

/lgtm

xpivarc · 2024-12-16T15:48:36Z

+1

Signed-off-by: Vladik Romanovsky <[email protected]>

fossedihelm · 2024-12-16T16:08:30Z

Thank you!
/lgtm

jean-edouard

/approve

kubevirt-bot · 2024-12-16T16:08:41Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jean-edouard

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~~ [jean-edouard]

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

kubevirt-bot added the dco-signoff: yes Indicates the PR's author has DCO signed all their commits. label Dec 2, 2024

kubevirt-bot requested review from aburdenthehand and dhiller December 2, 2024 15:38

kubevirt-bot added the size/M label Dec 2, 2024

dankenigsberg approved these changes Dec 3, 2024

View reviewed changes

kubevirt-bot assigned dankenigsberg Dec 3, 2024

kubevirt-bot added the lgtm Indicates that a PR is ready to be merged. label Dec 3, 2024

fabiand reviewed Dec 3, 2024

View reviewed changes

iholder101 reviewed Dec 3, 2024

View reviewed changes

vladikr force-pushed the new_vep branch from df948e2 to f03e66a Compare December 4, 2024 03:12

kubevirt-bot removed the lgtm Indicates that a PR is ready to be merged. label Dec 4, 2024

vladikr requested review from alicefr and Barakmor1 December 4, 2024 03:50

alicefr reviewed Dec 4, 2024

View reviewed changes

iholder101 mentioned this pull request Dec 4, 2024

github: Introduce a feature graduation tracker template kubevirt/kubevirt#13167

Closed

8 tasks

kubevirt-bot requested a review from jean-edouard December 4, 2024 15:07

vladikr requested a review from lyarwood December 4, 2024 23:14

lyarwood reviewed Dec 9, 2024

View reviewed changes

lyarwood mentioned this pull request Dec 11, 2024

design-proposals: Clean template and add feature lifecycle section #343

Closed

8 tasks

vladikr force-pushed the new_vep branch from f03e66a to dcbea5b Compare December 11, 2024 14:36

kubevirt-bot assigned lyarwood Dec 11, 2024

kubevirt-bot added the lgtm Indicates that a PR is ready to be merged. label Dec 11, 2024

lyarwood approved these changes Dec 11, 2024

View reviewed changes

enp0s3 approved these changes Dec 11, 2024

View reviewed changes

kubevirt-bot assigned enp0s3 Dec 11, 2024

dankenigsberg reviewed Dec 11, 2024

View reviewed changes

Barakmor1 reviewed Dec 15, 2024

View reviewed changes

vladikr force-pushed the new_vep branch from dcbea5b to dec9ad2 Compare December 15, 2024 18:06

kubevirt-bot removed the lgtm Indicates that a PR is ready to be merged. label Dec 15, 2024

enp0s3 approved these changes Dec 15, 2024

View reviewed changes

kubevirt-bot added the lgtm Indicates that a PR is ready to be merged. label Dec 15, 2024

Barakmor1 reviewed Dec 15, 2024

View reviewed changes

kubevirt-bot assigned Barakmor1 Dec 15, 2024

fossedihelm reviewed Dec 16, 2024

View reviewed changes

kubevirt-bot assigned iholder101 Dec 16, 2024

dankenigsberg approved these changes Dec 16, 2024

View reviewed changes

lyarwood approved these changes Dec 16, 2024

View reviewed changes

new process for handling virtualization proposals

da34b6b

Signed-off-by: Vladik Romanovsky <[email protected]>

vladikr force-pushed the new_vep branch from dec9ad2 to da34b6b Compare December 16, 2024 16:07

kubevirt-bot removed the lgtm Indicates that a PR is ready to be merged. label Dec 16, 2024

kubevirt-bot assigned fossedihelm Dec 16, 2024

kubevirt-bot added the lgtm Indicates that a PR is ready to be merged. label Dec 16, 2024

jean-edouard reviewed Dec 16, 2024

View reviewed changes

kubevirt-bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Dec 16, 2024

kubevirt-bot merged commit 57b24ac into kubevirt:main Dec 16, 2024
3 checks passed

This was referenced Dec 17, 2024

Add kubevirt/kubevirt approvers to this repository's OWNERS #297

Closed

enhancements: Propose a more formal yet lean enhancement process #288

Open

	4. Visibility and Tracking: The Author of an accepted VEPs will open an issue to track their progress, maturity stages (alpha, beta, GA), and list the associated bugs. And user feedback
	4. Visibility and Tracking: The Author of an accepted VEPs will open an issue to track their progress, maturity stages (alpha, beta, GA), list the associated bugs and user feedback

		5. Single source of truth*: Each VEP will be the authoritative reference for the associated feature. This aligns with the Kubernetes KEP process. It will ensure that each enhancement
		Includes all the relevant information, including the design and the state.


		## Repos

		- Impacted Repository: `kubevirt/enhancements` and kubevirt/community


		## Motivation

		KubeVirt’s current approach to proposals is unstructured and has outgrown the community repo, making it difficult to adequately manage both the repo and the design proposals. The current process does not provide a way to prioritize development and review efforts during the development cycle, nor is there a way to derive a roadmap for a specific release. The process also lacks any formal SIG involvement. Being in the community repo also makes it difficult to grow the reviewer and approver list as there are conflicting purposes.

	5. Single source of truth*: Each VEP will be the authoritative reference for the associated feature. This aligns with the Kubernetes KEP process. It will ensure that each enhancement
	Includes all the relevant information, including the design and the state.
	5. Single source of truth: Each VEP will be the authoritative reference for the associated feature. This aligns with the Kubernetes KEP process. It will ensure that each enhancement includes all the relevant information, including the design and the state.

New process for handling virtualization proposals #362

New process for handling virtualization proposals #362

Conversation

vladikr commented Dec 2, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fabiand left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

iholder101 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jean-edouard commented Dec 4, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lyarwood commented Dec 11, 2024

enp0s3 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vladikr commented Dec 15, 2024

Barakmor1 left a comment

Choose a reason for hiding this comment

Barakmor1 commented Dec 15, 2024

fossedihelm left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

iholder101 commented Dec 16, 2024

xpivarc commented Dec 16, 2024

fossedihelm commented Dec 16, 2024

jean-edouard left a comment

Choose a reason for hiding this comment

kubevirt-bot commented Dec 16, 2024