2nd iteration of the process

[xpivarc]

What this PR does / why we need it:
This PR is based on #7 and feedback provided on uncoference and by side channels.

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 #

Special notes for your reviewer:

Release note:

NONE

[dankenigsberg]

thanks for the update to the VEP process, here are very very partial nits

[dankenigsberg]

Suggested change

	**WHY**
	### WHY

[iholder101]

Good catch @dankenigsberg! though I think it should be ## (double, not triple 😄)

[dankenigsberg]

Suggested change

	- EF
	- EF: Enhancement Freeze

etc

[dankenigsberg]

Suggested change

	**Labels**
	### Labels

better use linkable md headers over manual formatting for subsections of the text.

[vladikr]

@orelmisan could you please take a look? Does this clarify some of the topics we discussed during the unconference?

[xpivarc]

/cc @alaypatel07 @lyarwood

[vladikr]

/cc @iholder101 @jean-edouard @Barakmor1 @0xFelix @fossedihelm @enp0s3

[vladikr]

/cc @alicefr

[0xFelix]

Do we want this for Beta/Stable too?

[0xFelix]

Suggested change

	The process aims to focus the community's efforts on prioritized pull requests, increase the review bandwidth, and ensure clear visibility of feature progress and associated issues. The relativly new split into SIGs requries defining common process to ensure synchronization between SIGs and uniformity of the project.
	The process aims to focus the community's efforts on prioritized pull requests, increase the review bandwidth, and ensure clear visibility of feature progress and associated issues. The relativly new split into SIGs requires defining a common process to ensure synchronization between SIGs and uniformity of the project.

[0xFelix]

Suggested change

	3. **SIG Review and Collaboration**: Each VEP will have a target SIG or more in case of cross SIG feature, and the SIGs will assign a dedicated reviewer to oversee the proposal, collaborate with others SIGs as needed, and provide feedback or veto when necessary. The author and reviewers work towards merged VEP.
	3. **SIG Review and Collaboration**: Each VEP will have one target SIG or more in case of a cross SIG feature, and the SIGs will assign a dedicated reviewer to oversee the proposal, collaborate with others SIGs as needed, and provide feedback or veto when necessary. The author and reviewers work towards merged VEP.

[0xFelix]

The author and reviewers work towards merged VEP

What does that mean? They work towards getting the VEP merged?

[0xFelix]

Suggested change

	Each SIG (Compute, Network, Storage) should sign-off the VEP with LGTM from representative (Sig-chair or approver of the sig) even if the proposal doesn't affect them. The sign-off works here as acknowledgment of the changes.
	Each SIG (Compute, Network, Storage) should sign-off the VEP with LGTM from a representative (Sig-chair or approver of the sig) even if the proposal doesn't affect them. The sign-off works here as acknowledgment of the changes.

[0xFelix]

Suggested change

	- Each week a release team will check tracked VEP in order to assure activity
	- Each week a release team will check tracked VEP in order to assure activity.

[0xFelix]

Suggested change

	Acceptance of enhancement doesn't guarantee that the feature will land in the current or later release. The process is collaborative effort between contributor/s and Approvers. Features not landing to release branch prior to FF will need to file for excepion, see <TODO>
	Acceptance of an enhancement doesn't guarantee that the feature will land in the current or later release. The process is a collaborative effort between contributor/s and Approvers. Features not landing to release branch prior to FF will need to file for an exception, see <TODO>

[0xFelix]

Suggested change

	The particular dealines are always changing based on the release and are publish <Link to repo>. The following deadlines are important for the VEP:
	The particular dealines are always changing based on the release and are published here: <Link to repo>. The following deadlines are important for the VEP:

[0xFelix]

We're already at this step?

[0xFelix]

Suggested change

	3. In case of exception not being granted, what is the impact? (Thing about graduation, maturity of the feature, user impact, etc.)
	3. In case of exception not being granted, what is the impact? (Think about graduation, maturity of the feature, user impact, etc.)

[0xFelix]

Should results of these check-ins be tracked somewhere? E.g. a comment on the VEP?

[iholder101]

+1. comment on the tracking issue is also what k8s are doing.

[jean-edouard]

This makes sense, I do worry that it might be too process-heavy, but we can always adjust in the future.
Many TODOs left, are they meant to be fixed by the 3rd iteration PR? If not, maybe this PR should be switched to draft.
See in-line for more, mostly typo fixes, nothing major.

[jean-edouard]

Suggested change

	The process aims to focus the community's efforts on prioritized pull requests, increase the review bandwidth, and ensure clear visibility of feature progress and associated issues. The relativly new split into SIGs requries defining common process to ensure synchronization between SIGs and uniformity of the project.
	The process aims to focus the community's efforts on prioritized pull requests, increase the review bandwidth, and ensure clear visibility of feature progress and associated issues. The relatively new split into SIGs requires defining a common process to ensure synchronization between SIGs and uniformity of the project.

[jean-edouard]

How do you fill a section that doesn't apply? Also:

Suggested change

	1. **VEP Creation**: VEP authors will initiate proposals via PRs to the `kubevirt/enhancements` repository. See what is required for every VEP - [Design proposal template](https://github.com/kubevirt/community/blob/main/design-proposals/proposal-template.md), each section needs to be filled even if the section doesn't apply to the VEP.
	1. **VEP Creation**: VEP authors will initiate proposals via PRs to the `kubevirt/enhancements` repository. See the [VEP template](https://github.com/kubevirt/enhancements/blob/main/veps/NNNN-vep-template/vep.md), each section needs to be filled even if the section doesn't apply to the VEP.

[jean-edouard]

Suggested change

	See what is required for every VEP's issue [Issue template](https://github.com/kubevirt/community/blob/main/design-proposals/proposal-template.md), each section should be filled.
	See the [VEP issue template](https://github.com/kubevirt/enhancements/blob/main/.github/ISSUE_TEMPLATE/vep.md), each section should be filled.

[jean-edouard]

Suggested change

	Each SIG (Compute, Network, Storage) should sign-off the VEP with LGTM from representative (Sig-chair or approver of the sig) even if the proposal doesn't affect them. The sign-off works here as acknowledgment of the changes.
	Each SIG (Compute, Network, Storage) should sign-off on the VEP with an LGTM from a SIG representative (chair or approver), even if the proposal doesn't affect them. The sign-off works here as acknowledgment of the changes.

[jean-edouard]

Suggested change

	Re-targeting could be also rejection of the VEP completly in case it is not implentable.
	Re-targeting could be also rejection of the VEP completely in case it is not implementable.

[jean-edouard]

Suggested change

	1. SIG labels - Each SIG will have a label in order to sort what SIGs is responsible for the VEP.
	1. SIG labels - Each SIG will have a label in order to sort which SIG is responsible for the VEP.

[jean-edouard]

Suggested change

	2. Target labels - There will be a lable in order to target the VEP for release.
	2. Target labels - There will be a label in order to target the VEP for release.

[jean-edouard]

Suggested change

	Acceptance of enhancement doesn't guarantee that the feature will land in the current or later release. The process is collaborative effort between contributor/s and Approvers. Features not landing to release branch prior to FF will need to file for excepion, see <TODO>
	Acceptance of enhancement doesn't guarantee that the feature will land in the current or later release. The process is a collaborative effort between contributors and approvers. Features not landing in the release branch prior to FF will need to file for an exception, see <TODO>

[jean-edouard]

Suggested change

	The particular dealines are always changing based on the release and are publish <Link to repo>. The following deadlines are important for the VEP:
	The particular dealines are always changing based on the release and are published <Link to repo>. The following deadlines are important for the VEP:

[jean-edouard]

Suggested change

	Typically an exeption would be asked to allow contributors to continue to working on VEP/PRs/code after the EF or FF respectivly.
	Typically an exception would be asked to allow contributors to continue to working on VEP/PRs/code after the EF or FF respectively.

[jean-edouard]

@0xFelix and I reviewed this at the exact same time, sorry for the duplicates...

[orelmisan]

Thank you for the PR @xpivarc.

Please consider making the README document dedicated mostly for VEP authors, for example:

1. What has to be done? in what order?
2. Whose signoffs do you need to have in order to move forward?
3. What are the deadlines?
4. Who do you need to contact in case you don't meet the deadlines? and how?

IMO it would help separating approver-specific content to a dedicated document, because having all the info here saturates VEP authors with info that is less relevant to them.

[vladikr]

Thank you for the PR @xpivarc.

Please consider making the README document dedicated mostly for VEP authors, for example:

1. What has to be done? in what order?
2. Whose signoffs do you need to have in order to move forward?
3. What are the deadlines?
4. Who do you need to contact in case you don't meet the deadlines? and how?

IMO it would help separating approver-specific content to a dedicated document, because having all the info here saturates VEP authors with info that is less relevant to them.

@orelmisan that's a good idea to have a focused view from the author's perspective. I feel that this could be a follow up. what do you think?
I would like first to see that process as a whole is understood and then we could create a dedicated view for the authors.

[alaypatel07]

There was a discussion topic raised in community meeting on March 12. How can VEP authors make sure that the VEP gets review cycles on the design?

There are certain steps that needs to be documented regarding this:

1. VEP authors should be encouraged to talk about the design in the unconference sessions to bring everyone on the same page about the problem, use-cases/design etc. Ideally this will help VEP authors to find a right sponsoring SIG for the VEP
2. VEP authors should join the relevant sig calls for further discussions, seeking for reviews
3. VEP authors can ask for reviews on community calls if this is a cross-sig VEP.

Documenting this would be essential for folks who are not familiar with the process, but have a design/feature that needs to be implemented in KubeVirt

cc @vladikr @awels please add thoughts that I missed from that discussion, thanks.

[awels]

Maybe we can add labels to the VEPs to help authors indicate which sigs they think they VEP belongs to? This will maybe also help get cross sig attention to the VEP.

[lyarwood]

Maybe we can add labels to the VEPs to help authors indicate which sigs they think they VEP belongs to? This will maybe also help get cross sig attention to the VEP.

Yup we should also adjust the PR template to ensure these are set from the start as they now are for the tracking issues.

[iholder101]

Great stuff @xpivarc! Thank you!

[iholder101]

nit

Suggested change

	- [ ] (R) Target version must be explicitly mentioned and approved
	- [ ] (R) Graduation criteria cannot be missing
	- [ ] (R) Target version is explicitly mentioned and approved
	- [ ] (R) Graduation criteria filled

[iholder101]

I would drop this one. If someone's interested, this is visible through git's history.

[lyarwood]

I'd move all of this PR tracking into additional context below as comment and mark it as optional.

[fossedihelm]

Why? I think it is great having the tracker issue as a single source of truth for the enhancement.

[iholder101]

I just don't understand which information this adds.
It links the updated VEP, and one can easily see the VEP changes through github, which is the source of truth for tracking VEP PR history. Copying & pasting PRs to over here could lead to human mistakes and duplicates a single source of truth to a second one.

I don't have a problem with what @lyarwood suggested, but I don't want to enforce yet another task on VEP owners, especially if it brings no new information. The process already carries a burden on VEP owners, so I want to keep it to the minimum necessary.

[iholder101]

I think this one can be dropped as well?

[iholder101]

Suggested change

	## Approvers responsibility
	## SIGs' responsibility

[iholder101]

My opinion is:
The VEP owner responsibility: coordinate between SIGs.
SIG responsibility: Prioritize VEP, decide if to track or not for the upcoming release, assign reviewers/approvers.

In other words, while each SIG has its own responsibilities, the VEP owner should be the one to do the actual coordination. As an example, if a VEP is owned by sig-compute but demands an ACK from sig-storage, the VEP owner should be joining the sig-storage meeting and ask for help.

[iholder101]

I'd remove the 1 week deadline and keep things a bit more vague.

Suggested change

	2. Coordination - SIGs are responsible that the reviews are not lacking behind for more than week. Release team is making sure there is an active SIG representative.
	2. Coordination - SIGs are responsible that the reviews are not lacking behind. Release team is making sure there is an active SIG representative.

[iholder101]

Can we list some examples? Such as:
/sig compute
/tracked no
/target alpha

(I hope these are correct. maybe @dhiller can keep me honest)

[dhiller]

The labels are all controlled via the prow label plugin.

Snippet from docs:

Labels of the following types can be manipulated: 'area/*',
'committee/*', 'kind/*', 'language/*', 'priority/*', 'sig/*',
'triage/*', and 'wg/*'.

leading to

• /sig compute
• /kind tracker (depends on whether the kind/tracker label is availalbe, see labels.md from l/project-infra)

What we need to do for custom labels like tracked/... and target/... is to create them in k/project-infra's labels.yaml and configure them to be usable in the labels plugin so that a defined group of people can use them. FYI - here's what labels kubernetes has

This would then enable comments like

/(remove-)label tracked/no
/(remove-)label target/alpha

which would then apply or remove the custom labels. If you already know which labels you need here, I'd be happy to help set up a PR. However, you should also think about the users who can apply those, so we can also create a GH team for this circle.

See here for examples:

• label plugin config
• label config

Happy to help here if required.

[iholder101]

Thanks @dhiller! This all looks great!

[iholder101]

Maybe add another step before these two:

• VEP planning - at the beginning of every release cycle, each SIG would prioritize VEPs and decide which ones are being tracked for the upcoming release.

[iholder101]

nit, typo:

Suggested change

	**How to ask for expection?**
	**How to ask for an expectation?**

[iholder101]

Maybe add:

How to raise attention for my VEP?
Every SIG has a recurring meeting. The VEP owner is encouraged to join the meeting and introduce the VEP to the community.

What if my VEP relates to more than one SIG?
VEPs can relate to multiple SIGs, but a single SIG should always own it. VEP owners can reach out to the SIG that seems most relevant for them. The SIG will either own the VEP or suggest that another SIG would own it.

As a VEP owner, can I change implementation and only then update the VEP?
While doing so is valid, it is discouraged. If an implementation was already merged but is ruled out as part of the VEP update this might lead to reverts, and the VEP owner should be aware of this risk. It is always recommended to merge a VEP update before starting to implement.

[iholder101]

Maybe we can add labels to the VEPs to help authors indicate which sigs they think they VEP belongs to? This will maybe also help get cross sig attention to the VEP.

I think it's already there?

enhancements/.github/ISSUE_TEMPLATE/vep.md

Line 41 in 6d7d5a7

/sig $SIG

[awels]

Looks like I was doing the process wrong, I never opened an issue, just the PR. Let me fix that.

[lyarwood]

supernit - vX.Y.0

[lyarwood]

I'd move all of this PR tracking into additional context below as comment and mark it as optional.

[lyarwood]

Target version for what? Alpha, Beta, GA or all of them? Would it be easier to say something like Feature lifecycle phase targets documented and approved in issue?

[fossedihelm]

done, thanks!

[fossedihelm]

@iholder101 @jean-edouard @0xFelix @vladikr I should have handled all the comments. PTAL

[iholder101]

This is for a target graduation. Targets are aspirations that might not happen in reality.
Do we want to add another section for the current phase?

[vladikr]

I think the current phase should be in the issue. The VEP is targeted to a specific phase.

[iholder101]

Suggested change

	- VEP
	- VEP: Virtualization Enhancement Proposal

[fossedihelm]

done

[iholder101]

Can we remove these? Or do we want to explain their meaning?

[fossedihelm]

done

[iholder101]

I'd avoid mentioning that this is work-in-progress.
de-facto, old design proposals are deprecated. It's true that we don't officially commit to VEPs yet, but a new user should definitely pick it over the old design proposals.

[vladikr]

I agree

[iholder101]

Suggested change

	## Process (DRAFT 2nd iteration)
	## Process

[iholder101]

Suggested change

	3. **SIG Review and Collaboration**: Each VEP will have one target SIG. In case of a cross SIG feature, the most relevant
	3. **SIG Review and Collaboration**: Although each VEP can have multiple target SIGs, it needs to have a single owning SIG. In case of a cross SIG feature, the most relevant

[iholder101]

To emphasize that the SIG is not responsible that the VEP is implemented but is committed to help the VEP owner to do so.

Suggested change

	The responsibility of the SIGs is to make sure the VEP is implemented, not diverging and that the implementation
	is not lacking behind the VEP, following this non-exhaustive list meant as checklist:
	The responsibility of the SIGs is to do their best to help ensure the VEP is implemented, not diverging and that the implementation
	is not lacking behind the VEP, following this non-exhaustive list meant as checklist:

[iholder101]

Awesome! 🎉
for the record: k8s have docs freeze and tests freeze, but I'm not sure we need those.

[fossedihelm]

For sure, we don't need them currently. :)

[iholder101]

<commented by mistake, can't delete it for some reason. please ignore.>

[fossedihelm]

Thanks @iholder101 addressed your comments

[vladikr]

Thank @fossedihelm !
To me, it looks good already. I think we can create a section dedicated only to the VEP author, as @orelmisan pointed out, as follow up.
I would prefer to merge this, to reflect what we have agreed on already and continue improving with follow ups.

/approve

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vladikr

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 [vladikr]

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

[fossedihelm]

Thank @fossedihelm ! To me, it looks good already. I think we can create a section dedicated only to the VEP author, as @orelmisan pointed out, as follow up. I would prefer to merge this, to reflect what we have agreed on already and continue improving with follow ups.

Of course, I agree and I would also prefer to leave it for a follow-up.
Thanks

[iholder101]

Thanks a lot @fossedihelm and everyone else involved. This is a great step forward!
/lgtm

Since so many people have participated in reviewing this, I'll hold this just to give others a chance to raise concerns if there are any. I think we can remove the hold within 24 hours if there are no objections.

/hold
@jean-edouard @alaypatel07 @dankenigsberg @lyarwood @orelmisan

[orelmisan]

Are we abandoning #7?

[fossedihelm]

Are we abandoning #7?

This PR includes #7 commits, so yes!